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xxiv Vol. 1 


CHAPTER 1 
ABOUT THIS MANUAL 


The Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1: Basic Architecture (order number 
253665) is part of a set that describes the architecture and programming environment of Intel® 64 and IA-32 
architecture processors. Other volumes in this set are: 


* The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A, 2B, 2C & 2D: Instruction Set 
Reference (order numbers 253666, 253667, 326018 and 334569). 


* The Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 3A, 3B, 3C & 3D: System 
Programming Guide (order numbers 253668, 253669, 326019 and 332831). 


° The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4: Model-Specific Registers 
(order number 335592), 


The Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, describes the basic architecture 
and programming environment of Intel 64 and IA-32 processors. The Inte/® 64 and IA-32 Architectures Software 
Developer’s Manual, Volumes 2A, 2B, 2C & 2D, describe the instruction set of the processor and the opcode struc- 
ture. These volumes apply to application programmers and to programmers who write operating systems or exec- 
utives. The Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 3A, 3B, 3C & 3D, describe 
the operating-system support environment of Intel 64 and IA-32 processors. These volumes target operating- 
system and BIOS designers. In addition, the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 3B, addresses the programming environment for classes of software that host operating systems. The 
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4, describes the model-specific registers 
of Intel 64 and IA-32 processors. 


1.1 INTEL® 64 AND IA-32 PROCESSORS COVERED IN THIS MANUAL 


This manual set includes information pertaining primarily to the most recent Intel 64 and IA-32 processors, which 
include: 


* Pentium® processors 

° P6 family processors 

* Pentium® 4 processors 

* Pentium® M processors 

* Intel® Xeon® processors 

* Pentium® D processors 

* Pentium® processor Extreme Editions 

* 64-bit Intel® Xeon® processors 

* Intel® Core™ Duo processor 

* Intel® Core™ Solo processor 

* Dual-Core Intel® Xeon® processor LV 

* Intel® Core™2 Duo processor 

* Intel® Core™2 Quad processor Q6000 series 

* Intel® xeon® processor 3000, 3200 series 

* Intel® Xeon® processor 5000 series 

* Intel® xeon® processor 5100, 5300 series 

* Intel® Core™2 Extreme processor X7000 and X6800 series 
* Intel® Core™2 Extreme processor QX6000 series 
* Intel® Xeon® processor 7100 series 
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* Intel® Pentium® Dual-Core processor 

* Intel® Xeon® processor 7200, 7300 series 

* Intel® xeon® processor 5200, 5400, 7400 series 

* Intel® Core™2 Extreme processor QX9000 and X9000 series 
* Intel® Core™2 Quad processor Q9000 series 

* Intel® Core™2 Duo processor E8000, T9000 series 

* Intel® Atom™ processor family 


* Intel® Atom™ processors 200, 300, D400, D500, D2000, N200, N400, N2000, E2000, Z500, Z600, Z2000, 
C1000 series are built from 45 nm and 32 nm processes 


* Intel® Core™ i7 processor 

* Intel® Core™ i5 processor 

* Intel® Xeon® processor E7-8800/4800/2800 product families 
* Intel® Core™ i7-3930K processor 

* 2nd generation Intel® Core™ i7-2xxx, Intel® Core™ i5-2xxx, Intel® Core™ i3-2xxx processor series 
* Intel® Xeon® processor E3-1200 product family 

* Intel® Xeon® processor E5-2400/1400 product family 

* Intel® Xeon® processor E5-4600/2600/1600 product family 
* 3rd generation Intel® Core™ processors 

* Intel® Xeon® processor E3-1200 v2 product family 

* Intel® Xeon® processor E5-2400/1400 v2 product families 

* Intel® Xeon® processor E5-4600/2600/1600 v2 product families 
* Intel® Xeon® processor E7-8800/4800/2800 v2 product families 
* 4th generation Intel® Core™ processors 

* The Intel® Core™ M processor family 

* Intel® Core™ i7-59xx Processor Extreme Edition 

* Intel® Core™ i7-49xx Processor Extreme Edition 

* Intel® Xeon® processor E3-1200 v3 product family 

* Intel® Xeon® processor E5-2600/1600 v3 product families 

* 5th generation Intel® Core™ processors 

* Intel® Xeon® processor D-1500 product family 

* Intel® Xeon® processor E5 v4 family 

* Intel® Atom™ processor X7-Z8000 and X5-Z8000 series 

* Intel® Atom™ processor Z3400 series 

* Intel® Atom™ processor Z3500 series 

* 6th generation Intel® Core™ processors 

* Intel® Xeon® processor E3-1500m v5 product family 

* 7th generation Intel® Core™ processors 

* Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series 

* Intel® Xeon® Processor Scalable Family 

* 8th generation Intel® Core™ processors 

* Intel® Xeon Phi™ Processor 7215, 7285, 7295 Series 

* Intel® Xeon® E processors 

* 9th generation Intel® Core™ processors 

* 2nd generation Intel® Xeon® Processor Scalable Family 
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* 10th generation Intel® Core™ processors 
* 11th generation Intel® Core™ processors 
* 3rd generation Intel® Xeon® Processor Scalable Family 


P6 family processors are IA-32 processors based on the P6 family microarchitecture. This includes the Pentium® 
Pro, Pentium® II, Pentium® Ill, and Pentium® III Xeon® processors. 


The Pentium® 4, Pentium® D, and Pentium® processor Extreme Editions are based on the Intel NetBurst® micro- 
architecture. Most early Intel® Xeon® processors are based on the Intel NetBurst® microarchitecture. Intel Xeon 
processor 5000, 7100 series are based on the Intel NetBurst® microarchitecture. 


The Intel® Core™ Duo, Intel® Core™ Solo and dual-core Intel® Xeon® processor LV are based on an improved 
Pentium® M processor microarchitecture. 


The Intel® Xeon® processor 3000, 3200, 5100, 5300, 7200, and 7300 series, Intel® Pentium® dual-core, Intel® 
Core™2 Duo, Intel® Core™2 Quad, and Intel® Core™2 Extreme processors are based on Intel® Core™ microarchi- 
tecture. 


The Intel® Xeon® processor 5200, 5400, 7400 series, Intel® Core™2 Quad processor Q9000 series, and Intel® 
Core™2 Extreme processors QX9000, X9000 series, Intel® Core™2 processor E8000 series are based on Enhanced 
Intel® Core™ microarchitecture. 


The Intel® Atom™ processors 200, 300, D400, D500, D2000, N200, N400, N2000, E2000, Z500, Z600, Z2000, 
C1000 series are based on the Intel® Atom™ microarchitecture and supports Intel 64 architecture. 


P6 family, Pentium® M, Intel® Core™ Solo, Intel® Core™ Duo processors, dual-core Intel® Xeon® processor LV, 
and early generations of Pentium 4 and Intel Xeon processors support IA-32 architecture. The Intel® Atom™ 
processor Z5xx series support IA-32 architecture. 


The Intel® Xeon® processor 3000, 3200, 5000, 5100, 5200, 5300, 5400, 7100, 7200, 7300, 7400 series, Intel® 
Core™ 2 Duo, Intel® Core™2 Extreme, Intel® Core™2 Quad processors, Pentium® D processors, Pentium® Dual- 
Core processor, newer generations of Pentium 4 and Intel Xeon processor family support Intel® 64 architecture. 


The Intel® Core™ i7 processor and Intel® Xeon® processor 3400, 5500, 7500 series are based on 45 nm Nehalem 
microarchitecture. Westmere microarchitecture is a 32 nm version of the Nehalem microarchitecture. Intel® 
Xeon® processor 5600 series, Intel Xeon processor E7 and various Intel Core i7, i5, i3 processors are based on the 
Westmere microarchitecture. These processors support Intel 64 architecture. 


The Intel® Xeon® processor E5 family, Intel® Xeon® processor E3-1200 family, Intel® Xeon® processor E7- 
8800/4800/2800 product families, Intel® Core™ i7-3930K processor, and 2nd generation Intel® Core™ i7-2xxx, 
Intel® Core™ i5-2xxx, Intel® Core™ i3-2xxx processor series are based on the Sandy Bridge microarchitecture and 
support Intel 64 architecture. 


The Intel® Xeon® processor E7-8800/4800/2800 v2 product families, Intel® Xeon® processor E3-1200 v2 product 
family and 3rd generation Intel® Core™ processors are based on the Ivy Bridge microarchitecture and support 
Intel 64 architecture. 


The Intel® Xeon® processor E5-4600/2600/1600 v2 product families, Intel® Xeon® processor E5-2400/1400 v2 
product families and Intel® Core™ i7-49xx Processor Extreme Edition are based on the Ivy Bridge-E microarchitec- 
ture and support Intel 64 architecture. 


The Intel® Xeon® processor E3-1200 v3 product family and 4th Generation Intel® Core™ processors are based on 
the Haswell microarchitecture and support Intel 64 architecture. 


The Intel® Xeon® processor E5-2600/1600 v3 product families and the Intel® Core™ i7-59xx Processor Extreme 
Edition are based on the Haswell-E microarchitecture and support Intel 64 architecture. 


The Intel® Atom™ processor Z8000 series is based on the Airmont microarchitecture. 


The Intel® Atom™ processor Z3400 series and the Intel® Atom™ processor Z3500 series are based on the Silver- 
mont microarchitecture. 


The Intel® Core™ M processor family, 5th generation Intel® Core™ processors, Intel® Xeon® processor D-1500 
product family and the Intel® Xeon® processor E5 v4 family are based on the Broadwell microarchitecture and 
support Intel 64 architecture. 


The Intel® Xeon® Processor Scalable Family, Intel® Xeon® processor E3-1500m v5 product family and 6th gener- 
ation Intel® Core™ processors are based on the Skylake microarchitecture and support Intel 64 architecture. 
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The 7th generation Intel® Core™ processors are based on the Kaby Lake microarchitecture and support Intel 64 
architecture. 


The Intel® Atom™ processor C series, the Intel® Atom™ processor X series, the Intel® Pentium® processor J 
series, the Intel® Celeron® processor J series, and the Intel® Celeron® processor N series are based on the Gold- 
mont microarchitecture. 


The Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series is based on the Knights Landing microarchitecture and 
supports Intel 64 architecture. 


The Intel® Pentium® Silver processor series, the Intel® Celeron® processor J series, and the Intel® Celeron® 
processor N series are based on the Goldmont Plus microarchitecture. 


The 8th generation Intel® Core™ processors, 9th generation Intel® Core™ processors, and Intel® Xeon® E proces- 
sors are based on the Coffee Lake microarchitecture and support Intel 64 architecture. 


The Intel® Xeon Phi™ Processor 7215, 7285, 7295 Series is based on the Knights Mill microarchitecture and 
supports Intel 64 architecture. 


The 2nd generation Intel® Xeon® Processor Scalable Family is based on the Cascade Lake product and supports 
Intel 64 architecture. 


Some 10th generation Intel® Core™ processors are based on the Ice Lake microarchitecture, and some are based 
on the Comet Lake microarchitecture; both support Intel 64 architecture. 


Some 11th generation Intel® Core™ processors are based on the Tiger Lake microarchitecture, and some are 
based on the Rocket Lake microarchitecture; both support Intel 64 architecture. 


Some 3rd generation Intel® Xeon® Processor Scalable Family processors are based on the Cooper Lake product, 
and some are based on the Ice Lake microarchitecture; both support Intel 64 architecture. 


IA-32 architecture is the instruction set architecture and programming environment for Intel's 32-bit microproces- 
sors. Intel® 64 architecture is the instruction set architecture and programming environment which is the superset 
of Intel’s 32-bit and 64-bit architectures. It is compatible with the IA-32 architecture. 


12 OVERVIEW OF VOLUME 1: BASIC ARCHITECTURE 


A description of this manual’s content follows: 


Chapter 1 — About This Manual. Gives an overview of all five volumes of the Inte/® 64 and IA-32 Architectures 
Software Developer’s Manual. It also describes the notational conventions in these manuals and lists related Intel 
manuals and documentation of interest to programmers and hardware designers. 


Chapter 2 — Intel® 64 and IA-32 Architectures. Introduces the Intel 64 and IA-32 architectures along with the 
families of Intel processors that are based on these architectures. It also gives an overview of the common features 
found in these processors and brief history of the Intel 64 and IA-32 architectures. 


Chapter 3 — Basic Execution Environment. Introduces the models of memory organization and describes the 
register set used by applications. 


Chapter 4 — Data Types. Describes the data types and addressing modes recognized by the processor; provides 
an overview of real numbers and floating-point formats and of floating-point exceptions. 


Chapter 5 — Instruction Set Summary. Lists all Intel 64 and IA-32 instructions, divided into technology groups. 


Chapter 6 — Procedure Calls, Interrupts, and Exceptions. Describes the procedure stack and mechanisms 
provided for making procedure calls and for servicing interrupts and exceptions. 


Chapter 7 — Programming with General-Purpose Instructions. Describes basic load and store, program 
control, arithmetic, and string instructions that operate on basic data types, general-purpose and segment regis- 
ters; also describes system instructions that are executed in protected mode. 


Chapter 8 — Programming with the x87 FPU. Describes the x87 floating-point unit (FPU), including floating- 
point registers and data types; gives an overview of the floating-point instruction set and describes the processor's 
floating-point exception conditions. 


Chapter 9 — Programming with Intel® MMX™ Technology. Describes Intel MMX technology, including MMX 
registers and data types; also provides an overview of the MMX instruction set. 
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Chapter 10 — Programming with Intel® Streaming SIMD Extensions (Intel® SSE). Describes SSE exten- 
sions, including XMM registers, the MXCSR register, and packed single-precision floating-point data types; provides 
an overview of the SSE instruction set and gives guidelines for writing code that accesses the SSE extensions. 


Chapter 11 — Programming with Intel® Streaming SIMD Extensions 2 (Intel® SSE2). Describes SSE2 
extensions, including XMM registers and packed double-precision floating-point data types; provides an overview 
of the SSE2 instruction set and gives guidelines for writing code that accesses SSE2 extensions. This chapter also 
describes SIMD floating-point exceptions that can be generated with SSE and SSE2 instructions. It also provides 
general guidelines for incorporating support for SSE and SSE2 extensions into operating system and applications 
code. 


Chapter 12 — Programming with Intel® Streaming SIMD Extensions 3 (Intel® SSE3), Supplemental 
Streaming SIMD Extensions 3 (SSSE3), Intel® Streaming SIMD Extensions 4 (Intel® SSE4) and Intel® 
AES New Instructions (Intel® AES-NI). Provides an overview of the SSE3 instruction set, Supplemental SSE3, 
SSE4, AESNI instructions, and guidelines for writing code that access these extensions. 


Chapter 13 — Managing State Using the XSAVE Feature Set. Describes the XSAVE feature set instructions 
and explains how software can enable the XSAVE feature set and XSAVE-enabled features. 


Chapter 14 — Programming with AVX, FMA and AVX2. Provides an overview of the Intel® AVX instruction set, 
FMA and Intel AVX2 extensions and gives guidelines for writing code that access these extensions. 


Chapter 15 — Programming with Intel® AVX-512. Provides an overview of the Intel® AVX-512 instruction set 
extensions and gives guidelines for writing code that access these extensions. 


Chapter 16 — Programming with Intel Transactional Synchronization Extensions. Describes the instruc- 
tion extensions that support lock elision techniques to improve the performance of multi-threaded software with 
contended locks. 


Chapter 17 — Intel® Memory Protection Extensions. Provides an overview of the Intel® Memory Protection 
Extensions and gives guidelines for writing code that access these extensions. 


Chapter 18 — Control-flow Enforcement Technology. Provides an overview of the Control-flow Enforcement 
Technology (CET) and gives guidelines for writing code that access these extensions. 


Chapter 19 — Input/Output. Describes the processor’s I/O mechanism, including I/O port addressing, I/O 
instructions, and I/O protection mechanisms. 


Chapter 20 — Processor Identification and Feature Determination. Describes how to determine the CPU 
type and features available in the processor. 


Appendix A — EFLAGS Cross-Reference. Summarizes how the IA-32 instructions affect the flags in the EFLAGS 
register. 


Appendix B — EFLAGS Condition Codes. Summarizes how conditional jump, move, and ‘byte set on condition 
code’ instructions use condition code flags (OF, CF, ZF, SF, and PF) in the EFLAGS register. 


Appendix C — Floating-Point Exceptions Summary. Summarizes exceptions raised by the x87 FPU floating- 
point and SSE/SSE2/SSE3 floating-point instructions. 


Appendix D — Guidelines for Writing SIMD Floating-Point Exception Handlers. Gives guidelines for writing 
exception handlers for exceptions generated by SSE/SSE2/SSE3 floating-point instructions. 


1:3 NOTATIONAL CONVENTIONS 


This manual uses specific notation for data-structure formats, for symbolic representation of instructions, and for 
hexadecimal and binary numbers. This notation is described below. 


1.3.1 Bit and Byte Order 


In illustrations of data structures in memory, smaller addresses appear toward the bottom of the figure; addresses 
increase toward the top. Bit positions are numbered from right to left. The numerical value of a set bit is equal to 
two raised to the power of the bit position. Intel 64 and IA-32 processors are “little endian” machines; this means 
the bytes of a word are numbered starting from the least significant byte. See Figure 1-1. 
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Data Structure 


Highest 
Address 32 24 23 16 15 8 7 O ~<«— Bit offset 


28 
24 
20 
16 
12 


Lowest 
A Address 


Byte Offset 


Figure 1-1. Bit and Byte Order 


1.3.2 Reserved Bits and Software Compatibility 


In many register and memory layout descriptions, certain bits are marked as reserved. When bits are marked as 
reserved, it is essential for compatibility with future processors that software treat these bits as having a future, 
though unknown, effect. The behavior of reserved bits should be regarded as not only undefined, but unpredict- 
able. 


Software should follow these guidelines in dealing with reserved bits: 


* Do not depend on the states of any reserved bits when testing the values of registers that contain such bits. 
Mask out the reserved bits before testing. 


* Do not depend on the states of any reserved bits when storing to memory or to a register. 
* Do not depend on the ability to retain information written into any reserved bits. 


¢ When loading a register, always load the reserved bits with the values indicated in the documentation, if any, or 
reload them with values previously read from the same register. 


NOTE 


Avoid any software dependence upon the state of reserved bits in Intel 64 and IA-32 registers. 
Depending upon the values of reserved register bits will make software dependent upon the 
unspecified manner in which the processor handles these bits. Programs that depend upon 
reserved values risk incompatibility with future processors. 


1.3.2.1 Instruction Operands 
When instructions are represented symbolically, a subset of the IA-32 assembly language is used. In this subset, 
an instruction has the following format: 
label: mnemonic argument1, argument2, argument3 
where: 
¢ A label is an identifier which is followed by a colon. 
¢ A mnemonic is a reserved name for a class of instruction opcodes which have the same function. 


¢ The operands argumenti, argument2, and argument3 are optional. There may be from zero to three 
operands, depending on the opcode. When present, they take the form of either literals or identifiers for data 
items. Operand identifiers are either reserved names of registers or are assumed to be assigned to data items 
declared in another part of the program (which may not be shown in the example). 


When two operands are present in an arithmetic or logical instruction, the right operand is the source and the left 
operand is the destination. 
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For example: 


LOADREG: MOV EAX, SUBTOTAL 


In this example, LOADREG is a label, MOV is the mnemonic identifier of an opcode, EAX is the destination operand, 
and SUBTOTAL is the source operand. Some assembly languages put the source and destination in reverse order. 


1.3.3 Hexadecimal and Binary Numbers 


Base 16 (hexadecimal) numbers are represented by a string of hexadecimal digits followed by the character H (for 
example, OF82EH). A hexadecimal digit is a character from the following set: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, 
E, and F. 


Base 2 (binary) numbers are represented by a string of 1s and 0s, sometimes followed by the character B (for 
example, 1010B). The “B” designation is only used in situations where confusion as to the type of number might 
arise. 


1.3.4 Segmented Addressing 


The processor uses byte addressing. This means memory is organized and accessed as a sequence of bytes. 
Whether one or more bytes are being accessed, a byte address is used to locate the byte or bytes memory. The 
range of memory that can be addressed is called an address space. 


The processor also supports segmented addressing. This is a form of addressing where a program may have many 
independent address spaces, called segments. For example, a program can keep its code (instructions) and stack 
in separate segments. Code addresses would always refer to the code space, and stack addresses would always 
refer to the stack space. The following notation is used to specify a byte address within a segment: 


Segment-register:Byte-address 


For example, the following segment address identifies the byte at address FF79H in the segment pointed by the DS 
register: 


DS:FF79H 


The following segment address identifies an instruction address in the code segment. The CS register points to the 
code segment and the EIP register contains the address of the instruction. 


CS:EIP 


1.3.5 A New Syntax for CPUID, CR, and MSR Values 


Obtain feature flags, status, and system information by using the CPUID instruction, by checking control register 
bits, and by reading model-specific registers. We are moving toward a new syntax to represent this information. 
See Figure 1-2. 
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CPUID Input and Output 


CPUID.01H:EDX.SSE[bit 25] = 1 
e | @ 


Input value for EAX register 


Output register and feature flag or field 
name with bit position(s) 


Value (or range) of output 


Control Register Values 


CR4.OSFXSR)Ibit 9] = 1 
e | © 


Example CR name 


Feature flag or field name 
with bit position(s) 


Value (or range) of output 


Model-Specific Register Values 


IA32_MISC_ENABLE.ENABLEFOPCODED[bit 2] = 1 
|! 


Example MSR name 


Feature flag or field name with bit position(s) 


Value (or range) of output 


Figure 1-2. Syntax for CPUID, CR, and MSR Data Presentation 


1.3.6 Exceptions 


An exception is an event that typically occurs when an instruction causes an error. For example, an attempt to 
divide by zero generates an exception. However, some exceptions, such as breakpoints, occur under other condi- 
tions. Some types of exceptions may provide error codes. An error code reports additional information about the 
error. An example of the notation used to show an exception and error code is shown below: 


#PF(fault code) 


This example refers to a page-fault exception under conditions where an error code naming a type of fault is 
reported. Under some conditions, exceptions that produce error codes may not be able to report an accurate code. 
In this case, the error code is zero, as shown below for a general-protection exception: 


#GP(0) 
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1.4 RELATED LITERATURE 


Literature related to Intel 64 and IA-32 processors is listed and viewable on-line at: 


https://software.intel.com/en-us/articles/intel-sdm 


See also: 


The latest security information on Intel® products: 
https://www.intel.com/content/www/us/en/security-center/default.html 


Software developer resources, guidance and insights for security advisories: 
https://software.intel.com/security-software-guidance/ 


The data sheet for a particular Intel 64 or IA-32 processor 
The specification update for a particular Intel 64 or IA-32 processor 


Intel® C++ Compiler documentation and online help: 
http://software.intel.com/en-us/articles/intel-compilers/ 


Intel® Fortran Compiler documentation and online help: 
http://software.intel.com/en-us/articles/intel-compilers/ 


Intel® Software Development Tools: 
https://software.intel.com/en-us/intel-sdp-home 


Intel® 64 and IA-32 Architectures Software Developer’s Manual (in one, four or ten volumes): 
https://software.intel.com/en-us/articles/intel-sdm 


Intel® 64 and IA-32 Architectures Optimization Reference Manual: 
https://software.intel.com/en-us/articles/intel-sdm#optimization 


Intel® Trusted Execution Technology Measured Launched Environment Programming Guide: 
http://www. intel.com/content/www/us/en/software-developers/intel-txt-software-development-guide.html 


Intel® Software Guard Extensions (Intel® SGX) Information 
https://software.intel.com/en-us/isa-extensions/intel-sgx 


Developing Multi-threaded Applications: A Platform Consistent Approach: 
https://software.intel.com/sites/default/files/article/147714/51534-developing-multithreaded-applica- 
tions. pdf 


Using Spin-Loops on Intel® Pentium® 4 Processor and Intel® Xeon® Processor: 
https://software.intel.com/sites/default/files/22/30/25602 


Performance Monitoring Unit Sharing Guide 
http://software.intel.com/file/30388 


Literature related to select features in future Intel processors are available at: 


Intel® Architecture Instruction Set Extensions Programming Reference 
https://software.intel.com/en-us/isa-extensions 


More relevant links are: 


Intel® Developer Zone: 

https://software.intel.com/en-us 

Developer centers: 

http://www. intel.com/content/www/us/en/hardware-developers/developer-centers.html 
Processor support general link: 

http://www. intel.com/support/processors/ 

Intel® Hyper-Threading Technology (Intel® HT Technology): 

http://www. intel.com/technology/platform-technology/hyper-threading/index.htm 
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CHAPTER 2 
INTEL® 64 AND IA-32 ARCHITECTURES 


2.1 BRIEF HISTORY OF INTEL® 64 AND IA-32 ARCHITECTURE 


The following sections provide a summary of the major technical evolutions from IA-32 to Intel 64 architecture: 
starting from the Intel 8086 processor to the latest Intel® Core® 2 Duo, Core 2 Quad and Intel Xeon processor 
5300 and 7300 series. Object code created for processors released as early as 1978 still executes on the latest 
processors in the Intel 64 and IA-32 architecture families. 


2441 16-bit Processors and Segmentation (1978) 


The IA-32 architecture family was preceded by 16-bit processors, the 8086 and 8088. The 8086 has 16-bit regis- 
ters and a 16-bit external data bus, with 20-bit addressing giving a 1-MByte address space. The 8088 is similar to 
the 8086 except it has an 8-bit external data bus. 


The 8086/8088 introduced segmentation to the IA-32 architecture. With segmentation, a 16-bit segment register 
contains a pointer to a memory segment of up to 64 KBytes. Using four segment registers at a time, 8086/8088 

processors are able to address up to 256 KBytes without switching between segments. The 20-bit addresses that 
can be formed using a segment register and an additional 16-bit pointer provide a total address range of 1 MByte. 


2.1.2 The Intel® 286 Processor (1982) 


The Intel 286 processor introduced protected mode operation into the IA-32 architecture. Protected mode uses the 
segment register content as selectors or pointers into descriptor tables. Descriptors provide 24-bit base addresses 
with a physical memory size of up to 16 MBytes, support for virtual memory management on a segment swapping 
basis, and a number of protection mechanisms. These mechanisms include: 


¢ Segment limit checking 
¢ Read-only and execute-only segment options 
° Four privilege levels 


2.1.3 The Intel386™ Processor (1985) 


The Intel386 processor was the first 32-bit processor in the IA-32 architecture family. It introduced 32-bit registers 
for use both to hold operands and for addressing. The lower half of each 32-bit Intel386 register retains the prop- 
erties of the 16-bit registers of earlier generations, permitting backward compatibility. The processor also provides 
a virtual-8086 mode that allows for even greater efficiency when executing programs created for 8086/8088 
processors. 


In addition, the Intel386 processor has support for: 

¢ A 32-bit address bus that supports up to 4-GBytes of physical memory 

¢ Asegmented-memory model and a flat memory model 

¢ Paging, with a fixed 4-KByte page size providing a method for virtual memory management 
* Support for parallel stages 


2.1.4 The Intel486™ Processor (1989) 


The Intel486" processor added more parallel execution capability by expanding the Intel386 processor’s instruc- 
tion decode and execution units into five pipelined stages. Each stage operates in parallel with the others on up to 
five instructions in different stages of execution. 
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In addition, the processor added: 


¢ An 8-KByte on-chip first-level cache that increased the percent of instructions that could execute at the scalar 
rate of one per clock 


¢ An integrated x87 FPU 
° Power saving and system management capabilities 


2.1.5 The Intel® Pentium® Processor (1993) 


The introduction of the Intel Pentium processor added a second execution pipeline to achieve superscalar perfor- 
mance (two pipelines, known as u and v, together can execute two instructions per clock). The on-chip first-level 
cache doubled, with 8 KBytes devoted to code and another 8 KBytes devoted to data. The data cache uses the MESI 
protocol to support more efficient write-back cache in addition to the write-through cache previously used by the 
Intel486 processor. Branch prediction with an on-chip branch table was added to increase performance in looping 
constructs. 


In addition, the processor added: 

¢ Extensions to make the virtual-8086 mode more efficient and allow for 4-MByte as well as 4-KByte pages 
¢ Internal data paths of 128 and 256 bits add speed to internal data transfers 

¢ Burstable external data bus was increased to 64 bits 

¢ An APIC to support systems with multiple processors 

¢ A dual processor mode to support glueless two processor systems 


A subsequent stepping of the Pentium family introduced Intel MMX technology (the Pentium Processor with MMX 
technology). Intel MMX technology uses the single-instruction, multiple-data (SIMD) execution model to perform 
parallel computations on packed integer data contained in 64-bit registers. 


See Section 2.2.7, “SIMD Instructions.” 


2.1.6 The P6 Family of Processors (1995-1999) 


The P6 family of processors was based on a superscalar microarchitecture that set new performance standards; see 
also Section 2.2.1, “P6 Family Microarchitecture.” One of the goals in the design of the P6 family microarchitecture 
was to exceed the performance of the Pentium processor significantly while using the same 0.6-micrometer, four- 
layer, metal BICMOS manufacturing process. Members of this family include the following: 


¢ The Intel Pentium Pro processor is three-way superscalar. Using parallel processing techniques, the 
processor is able on average to decode, dispatch, and complete execution of (retire) three instructions per 
clock cycle. The Pentium Pro introduced the dynamic execution (micro-data flow analysis, out-of-order 
execution, superior branch prediction, and speculative execution) in a superscalar implementation. The 
processor was further enhanced by its caches. It has the same two on-chip 8-KByte 1st-Level caches as the 
Pentium processor and an additional 256-KByte Level 2 cache in the same package as the processor. 


¢ The Intel Pentium II processor added Intel MMX technology to the P6 family processors along with new 
packaging and several hardware enhancements. The processor core is packaged in the single edge contact 
cartridge (SECC). The Level | data and instruction caches were enlarged to 16 KBytes each, and Level 2 cache 
sizes of 256 KBytes, 512 KBytes, and 1 MByte are supported. A half-frequency backside bus connects the Level 
2 cache to the processor. Multiple low-power states such as AutoHALT, Stop-Grant, Sleep, and Deep Sleep are 
supported to conserve power when idling. 


¢ The Pentium II Xeon processor combined the premium characteristics of previous generations of Intel 
processors. This includes: 4-way, 8-way (and up) scalability and a 2 MByte 2nd-Level cache running on a full- 
frequency backside bus. 


¢ The Intel Celeron processor family focused on the value PC market segment. Its introduction offers an 
integrated 128 KBytes of Level 2 cache and a plastic pin grid array (P.P.G.A.) form factor to lower system design 
cost. 


¢ The Intel Pentium Ill processor introduced the Streaming SIMD Extensions (SSE) to the IA-32 architecture. 
SSE extensions expand the SIMD execution model introduced with the Intel MMX technology by providing a 
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new set of 128-bit registers and the ability to perform SIMD operations on packed single-precision floating- 
point values. See Section 2.2.7, “SIMD Instructions.” 


¢ The Pentium Ill Xeon processor extended the performance levels of the IA-32 processors with the 
enhancement of a full-speed, on-die, and Advanced Transfer Cache. 


2.1.7. ‘The Intel® Pentium® 4 Processor Family (2000-2006) 


The Intel Pentium 4 processor family is based on Intel NetBurst microarchitecture; see Section 2.2.2, “Intel 
NetBurst® Microarchitecture.” 


The Intel Pentium 4 processor introduced Streaming SIMD Extensions 2 (SSE2); see Section 2.2.7, “SIMD Instruc- 
tions.” The Intel Pentium 4 processor 3.40 GHz, supporting Hyper-Threading Technology introduced Streaming 
SIMD Extensions 3 (SSE3); see Section 2.2.7, “SIMD Instructions.” 


Intel 64 architecture was introduced in the Intel Pentium 4 Processor Extreme Edition supporting Hyper-Threading 
Technology and in the Intel Pentium 4 Processor 6xx and 5xx sequences. 


Intel® Virtualization Technology (Intel® VT) was introduced in the Intel Pentium 4 processor 672 and 662. 


2.1.8 The Intel® Xeon® Processor (2001- 2007) 


Intel Xeon processors (with exception for dual-core Intel Xeon processor LV, Intel Xeon processor 5100 series) are 
based on the Intel NetBurst microarchitecture; see Section 2.2.2, “Intel NetBurst® Microarchitecture.” As a family, 
this group of IA-32 processors (more recently Intel 64 processors) is designed for use in multi-processor server 
systems and high-performance workstations. 


The Intel Xeon processor MP introduced support for Intel® Hyper-Threading Technology; see Section 2.2.8, “Intel® 
Hyper-Threading Technology.” 


The 64-bit Intel Xeon processor 3.60 GHz (with an 800 MHz System Bus) was used to introduce Intel 64 architec- 
ture. The Dual-Core Intel Xeon processor includes dual core technology. The Intel Xeon processor 70xx series 
includes Intel Virtualization Technology. 


The Intel Xeon processor 5100 series introduces power-efficient, high performance Intel Core microarchitecture. 
This processor is based on Intel 64 architecture; it includes Intel Virtualization Technology and dual-core tech- 
nology. The Intel Xeon processor 3000 series are also based on Intel Core microarchitecture. The Intel Xeon 
processor 5300 series introduces four processor cores in a physical package, they are also based on Intel Core 
microarchitecture. 


2.1.9 The Intel® Pentium® M Processor (2003-2006) 


The Intel Pentium M processor family is a high performance, low power mobile processor family with microarchitec- 
tural enhancements over previous generations of IA-32 Intel mobile processors. This family is designed for 
extending battery life and seamless integration with platform innovations that enable new usage models (such as 
extended mobility, ultra thin form-factors, and integrated wireless networking). 


Its enhanced microarchitecture includes: 
¢ Support for Intel Architecture with Dynamic Execution 


¢ A high performance, low-power core manufactured using Intel’s advanced process technology with copper 
interconnect 


* On-die, primary 32-KByte instruction cache and 32-KByte write-back data cache 

° On-die, second-level cache (up to 2 MByte) with Advanced Transfer Cache Architecture 
¢ Advanced Branch Prediction and Data Prefetch Logic 

¢ Support for MMX technology, Streaming SIMD instructions, and the SSE2 instruction set 
° A400 or 533 MHz, Source-Synchronous Processor System Bus 

* Advanced power management using Enhanced Intel SpeedStep® technology 
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2.1.10 The Intel® Pentium® Processor Extreme Edition (2005) 


The Intel Pentium processor Extreme Edition introduced dual-core technology. This technology provides advanced 
hardware multi-threading support. The processor is based on Intel NetBurst microarchitecture and supports SSE, 
SSE2, SSE3, Hyper-Threading Technology, and Intel 64 architecture. 


See also: 

* Section 2.2.2, “Intel NetBurst® Microarchitecture” 

* Section 2.2.3, “Intel® Core™ Microarchitecture” 

® Section 2.2.7, “SIMD Instructions” 

° Section 2.2.8, “Intel® Hyper-Threading Technology” 
¢ Section 2.2.9, “Multi-Core Technology” 

* Section 2.2.10, “Intel® 64 Architecture” 


2.1.11. The Intel® Core™ Duo and Intel® Core™ Solo Processors (2006-2007) 


The Intel Core Duo processor offers power-efficient, dual-core performance with a low-power design that extends 
battery life. This family and the single-core Intel Core Solo processor offer microarchitectural enhancements over 
Pentium M processor family. 


Its enhanced microarchitecture includes: 

* Intel® Smart Cache which allows for efficient data sharing between two processor cores 

* Improved decoding and SIMD execution 

* Intel® Dynamic Power Coordination and Enhanced Intel® Deeper Sleep to reduce power consumption 
* Intel® Advanced Thermal Manager which features digital thermal sensor interfaces 

¢ Support for power-optimized 667 MHz bus 


The dual-core Intel Xeon processor LV is based on the same microarchitecture as Intel Core Duo processor, and 
supports IA-32 architecture. 


2.1.12 The Intel® Xeon® Processor 5100, 5300 Series and Intel® Core™ 2 Processor Family 
(2006) 


The Intel Xeon processor 3000, 3200, 5100, 5300, and 7300 series, Intel Pentium Dual-Core, Intel Core 2 Extreme, 
Intel Core 2 Quad processors, and Intel Core 2 Duo processor family support Intel 64 architecture; they are based 
on the high-performance, power-efficient Intel® Core microarchitecture built on 65 nm process technology. The 
Intel Core microarchitecture includes the following innovative features: 


* Intel® Wide Dynamic Execution to increase performance and execution throughput 

* Intel® Intelligent Power Capability to reduce power consumption 

* Intel® Advanced Smart Cache which allows for efficient data sharing between two processor cores 
* Intel® Smart Memory Access to increase data bandwidth and hide latency of memory accesses 


* Intel® Advanced Digital Media Boost which improves application performance using multiple generations of 
Streaming SIMD extensions 


The Intel Xeon processor 5300 series, Intel Core 2 Extreme processor QX6800 series, and Intel Core 2 Quad 
processors support Intel quad-core technology. 


2.1.13. The Intel® Xeon® Processor 5200, 5400, 7400 Series and Intel® Core™ 2 Processor 
Family (2007) 


The Intel Xeon processor 5200, 5400, and 7400 series, Intel Core 2 Quad processor Q9000 Series, Intel Core 2 Duo 
processor E8000 series support Intel 64 architecture; they are based on the Enhanced Intel® Core microarchitec- 
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ture using 45 nm process technology. The Enhanced Intel Core microarchitecture provides the following improved 
features: 


* A radix-16 divider, faster OS primitives further increases the performance of Intel® Wide Dynamic Execution. 


* Improves Intel® Advanced Smart Cache with Up to 50% larger level-two cache and up to 50% increase in way- 
set associativity. 


* A 128-bit shuffler engine significantly improves the performance of Intel® Advanced Digital Media Boost and 
SSE4. 


Intel Xeon processor 5400 series and Intel Core 2 Quad processor Q9000 Series support Intel quad-core tech- 
nology. Intel Xeon processor 7400 series offers up to six processor cores and an L3 cache up to 16 MBytes. 


2.1.14 The Intel® Atom™ Processor Family (2008) 


The first generation of Intel® Atom™ processors are built on 45 nm process technology. They are based on a new 
microarchitecture, Intel® Atom™ microarchitecture, which is optimized for ultra low power devices. The Intel® 
Atom™ microarchitecture features two in-order execution pipelines that minimize power consumption, increase 
battery life, and enable ultra-small form factors. The initial Intel Atom Processor family and subsequent generations including 
Intel Atom processor D2000, N2000, E2000, 22000, C1000 series provide the following features: 


* Enhanced Intel® SpeedStep® Technology 
* Intel® Hyper-Threading Technology 
¢ Deep Power Down Technology with Dynamic Cache Sizing 


¢* Support for instruction set extensions up to and including Supplemental Streaming SIMD Extensions 3 
(SSSE3). 


* Support for Intel® Virtualization Technology 
* Support for Intel® 64 Architecture (excluding Intel Atom processor Z5xx Series) 


2.1.15 The Intel® Atom™ Processor Family Based on Silvermont Microarchitecture (2013) 


Intel Atom Processor C2xxx, E3xxx, S1xxx series are based on the Silvermont microarchitecture. Processors based on the Silvermont 
microarchitecture supports instruction set extensions up to and including SSE4.2, AESNI, and PCLMULQDQ. 


2.1.16 The Intel® Core i7 Processor Family (2008) 


The Intel Core i7 processor 900 series support Intel 64 architecture; they are based on Intel® microarchitecture 
code name Nehalem using 45 nm process technology. The Intel Core i7 processor and Intel Xeon processor 5500 
series include the following innovative features: 


* Intel® Turbo Boost Technology converts thermal headroom into higher performance. 

* Intel® HyperThreading Technology in conjunction with Quadcore to provide four cores and eight threads. 
* Dedicated power control unit to reduce active and idle power consumption. 

¢ Integrated memory controller on the processor supporting three channel of DDR3 memory. 

* 8 MB inclusive Intel® Smart Cache. 

* Intel® QuickPath interconnect (QPI) providing point-to-point link to chipset. 

¢ Support for SSE4.2 and SSE4.1 instruction sets. 

¢ Second generation Intel Virtualization Technology. 


2.1.17. The Intel® Xeon® Processor 7500 Series (2010) 


The Intel Xeon processor 7500 and 6500 series are based on Intel microarchitecture code name Nehalem using 45 
nm process technology. They support the same features described in Section 2.1.16, plus the following innovative 
features: 
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° Up to eight cores per physical processor package. 
* Up to 24 MB inclusive Intel® Smart Cache. 


* Provides Intel® Scalable Memory Interconnect (Intel® SMI) channels with Intel® 7500 Scalable Memory Buffer 
to connect to system memory. 


¢ Advanced RAS supporting software recoverable machine check architecture. 


2.1.18 2010 Intel® Core™ Processor Family (2010) 


2010 Intel Core processor family spans Intel Core i7, i5 and i3 processors. They are based on Intel® microarchitec- 
ture code name Westmere using 32 nm process technology. The innovative features can include: 


® Deliver smart performance using Intel Hyper-Threading Technology plus Intel Turbo Boost Technology. 
® Enhanced Intel Smart Cache and integrated memory controller. 

¢ Intelligent power gating. 

¢  Repartitioned platform with on-die integration of 45 nm integrated graphics. 

® Range of instruction set support up to AESNI, PCLMULQDQ, SSE4.2 and SSE4.1. 


2.1.19 The Intel® Xeon® Processor 5600 Series (2010) 


The Intel Xeon processor 5600 series are based on Intel microarchitecture code name Westmere using 32 nm 
process technology. They support the same features described in Section 2.1.16, plus the following innovative 
features: 


° Up to six cores per physical processor package. 

* Up to 12 MB enhanced Intel® Smart Cache. 

® Support for AESNI, PCLMULQDQ, SSE4.2 and SSE4.1 instruction sets. 
e  =Flexible Intel Virtualization Technologies across processor and I/O. 


2.1.20 The Second Generation Intel® Core™ Processor Family (2011) 


The Second Generation Intel Core processor family spans Intel Core i7, i5 and i3 processors based on the Sandy 
Bridge microarchitecture. They are built from 32 nm process technology and have innovative features including: 


¢ Intel Turbo Boost Technology for Intel Core i5 and i7 processors 

¢ Intel Hyper-Threading Technology. 

¢ Enhanced Intel Smart Cache and integrated memory controller. 

* Processor graphics and built-in visual features like Intel® Quick Sync Video, Intel® Insider™ etc. 

® Range of instruction set support up to AVX, AESNI, PCLMULQDQ, SSE4.2 and SSE4.1. 

Intel Xeon processor E3-1200 product family is also based on the Sandy Bridge microarchitecture. 

Intel Xeon processor E5-2400/1400 product families are based on the Sandy Bridge-EP microarchitecture. 


Intel Xeon processor E5-4600/2600/1600 product families are based on the Sandy Bridge-EP microarchitecture 
and provide support for multiple sockets. 


2.1.21 The Third Generation Intel® Core™ Processor Family (2012) 


The Third Generation Intel Core processor family spans Intel Core i7, iS and i3 processors based on the Ivy Bridge 
microarchitecture. The Intel Xeon processor E7-8800/4800/2800 v2 product families and Intel Xeon processor E3- 
1200 v2 product family are also based on the Ivy Bridge microarchitecture. 


The Intel Xeon processor E5-2400/1400 v2 product families are based on the Ivy Bridge-EP microarchitecture. 
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The Intel Xeon processor E5-4600/2600/1600 v2 product families are based on the Ivy Bridge-EP microarchitec- 
ture and provide support for multiple sockets. 


2.1.22 The Fourth Generation Intel® Core™ Processor Family (2013) 


The Fourth Generation Intel Core processor family spans Intel Core i7, i5 and i3 processors based on the Haswell 
microarchitecture. Intel Xeon processor E3-1200 v3 product family is also based on the Haswell microarchitecture. 


2.2 MORE ON SPECIFIC ADVANCES 


The following sections provide more information on major innovations. 


2.2.1 P6 Family Microarchitecture 


The Pentium Pro processor introduced a new microarchitecture commonly referred to as P6 processor microarchi- 
tecture. The P6 processor microarchitecture was later enhanced with an on-die, Level 2 cache, called Advanced 
Transfer Cache. 


The microarchitecture is a three-way superscalar, pipelined architecture. Three-way superscalar means that by 
using parallel processing techniques, the processor is able on average to decode, dispatch, and complete execution 
of (retire) three instructions per clock cycle. To handle this level of instruction throughput, the P6 processor family 
uses a decoupled, 12-stage superpipeline that supports out-of-order instruction execution. 


Figure 2-1 shows a conceptual view of the P6 processor microarchitecture pipeline with the Advanced Transfer 
Cache enhancement. 
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Figure 2-1. The P6 Processor Microarchitecture with Advanced Transfer Cache Enhancement 


To ensure a steady supply of instructions and data for the instruction execution pipeline, the P6 processor microar- 
chitecture incorporates two cache levels. The Level 1 cache provides an 8-KByte instruction cache and an 8-KByte 
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data cache, both closely coupled to the pipeline. The Level 2 cache provides 256-KByte, 512-KByte, or 1-MByte 
static RAM that is coupled to the core processor through a full clock-speed 64-bit cache bus. 


The centerpiece of the P6 processor microarchitecture is an out-of-order execution mechanism called dynamic 
execution. Dynamic execution incorporates three data-processing concepts: 


Deep branch prediction allows the processor to decode instructions beyond branches to keep the instruction 
pipeline full. The P6 processor family implements highly optimized branch prediction algorithms to predict the 
direction of the instruction. 


Dynamic data flow analysis requires real-time analysis of the flow of data through the processor to 
determine dependencies and to detect opportunities for out-of-order instruction execution. The out-of-order 
execution core can monitor many instructions and execute these instructions in the order that best optimizes 
the use of the processor’s multiple execution units, while maintaining the data integrity. 


Speculative execution refers to the processor’s ability to execute instructions that lie beyond a conditional 
branch that has not yet been resolved, and ultimately to commit the results in the order of the original 
instruction stream. To make speculative execution possible, the P6 processor microarchitecture decouples the 
dispatch and execution of instructions from the commitment of results. The processor’s out-of-order execution 
core uses data-flow analysis to execute all available instructions in the instruction pool and store the results in 
temporary registers. The retirement unit then linearly searches the instruction pool for completed instructions 
that no longer have data dependencies with other instructions or unresolved branch predictions. When 
completed instructions are found, the retirement unit commits the results of these instructions to memory 
and/or the IA-32 registers (the processor's eight general-purpose registers and eight x87 FPU data registers) 
in the order they were originally issued and retires the instructions from the instruction pool. 


2.2.2 Intel NetBurst® Microarchitecture 


The Intel NetBurst microarchitecture provides: 


The Rapid Execution Engine 
— Arithmetic Logic Units (ALUs) run at twice the processor frequency 
— Basic integer operations can dispatch in 1/2 processor clock tick 
Hyper-Pipelined Technology 
— Deep pipeline to enable industry-leading clock rates for desktop PCs and servers 
— Frequency headroom and scalability to continue leadership into the future 
Advanced Dynamic Execution 
— Deep, out-of-order, speculative execution engine 
¢ Up to 126 instructions in flight 
* Up to 48 loads and 24 stores in pipeline! 
— Enhanced branch prediction capability 
* Reduces the misprediction penalty associated with deeper pipelines 
¢ Advanced branch prediction algorithm 
¢ 4K-entry branch target array 
New cache subsystem 
— First level caches 
¢ Advanced Execution Trace Cache stores decoded instructions 
¢ Execution Trace Cache removes decoder latency from main execution loops 


¢ Execution Trace Cache integrates path of program execution flow into a single line 


Intel 64 and IA-32 processors based on the Intel NetBurst microarchitecture at 90 nm process can handle more than 24 stores in 
flight. 
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¢ Low latency data cache 

— Second level cache 
¢  Full-speed, unified 8-way Level 2 on-die Advance Transfer Cache 
¢ Bandwidth and performance increases with processor frequency 


High-performance, quad-pumped bus interface to the Intel NetBurst microarchitecture system bus 
— Supports quad-pumped, scalable bus clock to achieve up to 4X effective speed 


— Capable of delivering up to 8.5 GBytes of bandwidth per second 
Superscalar issue to enable parallelism 


Expanded hardware registers with renaming to avoid register name space limitations 


64-byte cache line size (transfers data up to two lines per sector) 
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Figure 2-2 is an overview of the Intel NetBurst microarchitecture. This microarchitecture pipeline is made up of 
three sections: (1) the front end pipeline, (2) the out-of-order execution core, and (3) the retirement unit. 
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Figure 2-2. The Intel NetBurst Microarchitecture 


2.2.2.1 The Front End Pipeline 


The front end supplies instructions in program order to the out-of-order execution core. It performs a number of 
functions: 


Prefetches instructions that are likely to be executed 

Fetches instructions that have not already been prefetched 

Decodes instructions into micro-operations 

Generates microcode for complex instructions and special-purpose code 
Delivers decoded instructions from the execution trace cache 
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¢ Predicts branches using highly advanced algorithm 


The pipeline is designed to address common problems in high-speed, pipelined microprocessors. Two of these 
problems contribute to major sources of delays: 


° time to decode instructions fetched from the target 
* wasted decode bandwidth due to branches or branch target in the middle of cache lines 


The operation of the pipeline’s trace cache addresses these issues. Instructions are constantly being fetched and 
decoded by the translation engine (part of the fetch/decode logic) and built into sequences of micro-ops called 
traces. At any time, multiple traces (representing prefetched branches) are being stored in the trace cache. The 
trace cache is searched for the instruction that follows the active branch. If the instruction also appears as the first 
instruction in a pre-fetched branch, the fetch and decode of instructions from the memory hierarchy ceases and the 
pre-fetched branch becomes the new source of instructions (see Figure 2-2). 


The trace cache and the translation engine have cooperating branch prediction hardware. Branch targets are 
predicted based on their linear addresses using branch target buffers (BTBs) and fetched as soon as possible. 


2.2.2.2 Out-Of-Order Execution Core 


The out-of-order execution core’s ability to execute instructions out of order is a key factor in enabling parallelism. 
This feature enables the processor to reorder instructions so that if one micro-op is delayed, other micro-ops may 
proceed around it. The processor employs several buffers to smooth the flow of micro-ops. 


The core is designed to facilitate parallel execution. It can dispatch up to six micro-ops per cycle (this exceeds trace 
cache and retirement micro-op bandwidth). Most pipelines can start executing a new micro-op every cycle, so 
several instructions can be in flight at a time for each pipeline. A number of arithmetic logical unit (ALU) instruc- 
tions can start at two per cycle; many floating-point instructions can start once every two cycles. 


2.2.2.3 Retirement Unit 


The retirement unit receives the results of the executed micro-ops from the out-of-order execution core and 
processes the results so that the architectural state updates according to the original program order. 


When a micro-op completes and writes its result, it is retired. Up to three micro-ops may be retired per cycle. The 
Reorder Buffer (ROB) is the unit in the processor which buffers completed micro-ops, updates the architectural 
state in order, and manages the ordering of exceptions. The retirement section also keeps track of branches and 
sends updated branch target information to the BTB. The BTB then purges pre-fetched traces that are no longer 
needed. 


2.2.3 Intel® Core™ Microarchitecture 


Intel Core microarchitecture introduces the following features that enable high performance and power-efficient 
performance for single-threaded as well as multi-threaded workloads: 


* Intel® Wide Dynamic Execution enable each processor core to fetch, dispatch, execute in high bandwidths 
to support retirement of up to four instructions per cycle. 


— Fourteen-stage efficient pipeline 

— Three arithmetic logical units 

— Four decoders to decode up to five instruction per cycle 

— Macro-fusion and micro-fusion to improve front-end throughput 

— Peak issue rate of dispatching up to six micro-ops per cycle 

— Peak retirement bandwidth of up to 4 micro-ops per cycle 

— Advanced branch prediction 

— Stack pointer tracker to improve efficiency of executing function/procedure entries and exits 


* Intel® Advanced Smart Cache delivers higher bandwidth from the second level cache to the core, and 
optimal performance and flexibility for single-threaded and multi-threaded applications. 
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— Large second level cache up to 4 MB and 16-way associativity 
— Optimized for multicore and single-threaded execution environments 
— 256 bit internal data path to improve bandwidth from L2 to first-level data cache 


* Intel® Smart Memory Access prefetches data from memory in response to data access patterns and reduces 
cache-miss exposure of out-of-order execution. 


— Hardware prefetchers to reduce effective latency of second-level cache misses 
— Hardware prefetchers to reduce effective latency of first-level data cache misses 
— Memory disambiguation to improve efficiency of speculative execution execution engine 


* Intel® Advanced Digital Media Boost improves most 128-bit SIMD instruction with single-cycle throughput 
and floating-point operations. 


— Single-cycle throughput of most 128-bit SIMD instructions 
— Up to eight floating-point operation per cycle 
— Three issue ports available to dispatching SIMD instructions for execution 


Intel Core 2 Extreme, Intel Core 2 Duo processors and Intel Xeon processor 5100 series implement two processor 
cores based on the Intel Core microarchitecture, the functionality of the subsystems in each core are depicted in 
Figure 2-3. 
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Figure 2-3. The Intel Core Microarchitecture Pipeline Functionality 


2.2.3.1 The Front End 


The front end of Intel Core microarchitecture provides several enhancements to feed the Intel Wide Dynamic 
Execution engine: 


¢ Instruction fetch unit prefetches instructions into an instruction queue to maintain steady supply of instruction 
to the decode units. 


¢ Four-wide decode unit can decode 4 instructions per cycle or 5 instructions per cycle with Macrofusion. 
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Macrofusion fuses common sequence of two instructions as one decoded instruction (micro-ops) to increase 
decoding throughput. 


Microfusion fuses common sequence of two micro-ops as one micro-ops to improve retirement throughput. 
Instruction queue provides caching of short loops to improve efficiency. 
Stack pointer tracker improves efficiency of executing procedure/function entries and exits. 


Branch prediction unit employs dedicated hardware to handle different types of branches for improved branch 
prediction. 


Advanced branch prediction algorithm directs instruction fetch unit to fetch instructions likely in the architec- 
tural code path for decoding. 


2.2.3.2 Execution Core 


The execution core of the Intel Core microarchitecture is superscalar and can process instructions out of order to 
increase the overall rate of instructions executed per cycle (IPC). The execution core employs the following feature 
to improve execution throughput and efficiency: 


Up to six micro-ops can be dispatched to execute per cycle 

Up to four instructions can be retired per cycle 

Three full arithmetic logical units 

SIMD instructions can be dispatched through three issue ports 

Most SIMD instructions have 1-cycle throughput (including 128-bit SIMD instructions) 

Up to eight floating-point operation per cycle 

Many long-latency computation operation are pipelined in hardware to increase overall throughput 
Reduced exposure to data access delays using Intel Smart Memory Access 


2.2.4 Intel® Atom™ Microarchitecture 


Intel Atom microarchitecture maximizes power-efficient performance for single-threaded and multi-threaded 
workloads by providing: 


Advanced Micro-Ops Execution 


— Single-micro-op instruction execution from decode to retirement, including instructions with register-only, 
load, and store semantics. 


— Sixteen-stage, in-order pipeline optimized for throughput and reduced power consumption. 

— Dual pipelines to enable decode, issue, execution and retirement of two instructions per cycle. 
— Advanced stack pointer to improve efficiency of executing function entry/returns. 

Intel® Smart Cache 

— Second level cache is 512 KB and 8-way associativity. 

— Optimized for multi-threaded and single-threaded execution environments 

— 256 bit internal data path between L2 and L1 data cache improves high bandwidth. 

Efficient Memory Access 


— Efficient hardware prefetchers to L1 and L2, speculatively loading data likely to be requested by processor 
to reduce cache miss impact. 


Intel® Digital Media Boost 

— Two issue ports for dispatching SIMD instructions to execution units. 
— Single-cycle throughput for most 128-bit integer SIMD instructions 
— Upto six floating-point operations per cycle 

— Up to two 128-bit SIMD integer operations per cycle 
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Safe Instruction Recognition (SIR) to allow long-latency floating-point operations to retire out of order with 
respect to integer instructions. 


Intel® Microarchitecture Code Name Nehalem 


Intel microarchitecture code name Nehalem provides the foundation for many innovative features of Intel Core i7 
processors. It builds on the success of 45 nm Intel Core microarchitecture and provides the following feature 
enhancements: 


¢ Enhanced processor core 


Improved branch prediction and recovery from misprediction. 

Enhanced loop streaming to improve front end performance and reduce power consumption. 
Deeper buffering in out-of-order engine to extract parallelism. 

Enhanced execution units to provide acceleration in CRC, string/text processing and data shuffling. 


¢ Smart Memory Access 


Integrated memory controller provides low-latency access to system memory and scalable memory 
bandwidth 


New cache hierarchy organization with shared, inclusive L3 to reduce snoop traffic 
Two level TLBs and increased TLB size. 
Fast unaligned memory access. 


¢ HyperThreading Technology 


Provides two hardware threads (logical processors) per core. 
Takes advantage of 4-wide execution engine, large L3, and massive memory bandwidth. 


¢ Dedicated Power management Innovations 


2.2.6 


Integrated microcontroller with optimized embedded firmware to manage power consumption. 
Embedded real-time sensors for temperature, current, and power. 

Integrated power gate to turn off/on per-core power consumption 

Versatility to reduce power consumption of memory, link subsystems. 


Intel® Microarchitecture Code Name Sandy Bridge 


Intel® microarchitecture code name Sandy Bridge builds on the successes of Intel® Core™ microarchitecture and 
Intel microarchitecture code name Nehalem. It offers the following innovative features: 


¢ Intel Advanced Vector Extensions (Intel AVX) 


256-bit floating-point instruction set extensions to the 128-bit Intel Streaming SIMD Extensions, providing 
up to 2X performance benefits relative to 128-bit code. 


Non-destructive destination encoding offers more flexible coding techniques. 


Supports flexible migration and co-existence between 256-bit AVX code, 128-bit AVX code and legacy 128- 
bit SSE code. 


¢ Enhanced front-end and execution engine 


New decoded Icache component that improves front-end bandwidth and reduces branch misprediction 
penalty. 


Advanced branch prediction. 

Additional macro-fusion support. 

Larger dynamic execution window. 

Multi-precision integer arithmetic enhancements (ADC/SBB, MUL/IMUL). 


Vol.1 2-13 


INTEL® 64 AND IA-32 ARCHITECTURES 


— LEA bandwidth improvement. 
— Reduction of general execution stalls (read ports, writeback conflicts, bypass latency, partial stalls). 
— Fast floating-point exception handling. 
— XSAVE/XRSTORE performance improvements and XSAVEOPT new instruction. 
® Cache hierarchy improvements for wider data path 
— Doubling of bandwidth enabled by two symmetric ports for memory operation. 
— Simultaneous handling of more in-flight loads and stores enabled by increased buffers. 
— Internal bandwidth of two loads and one store each cycle. 
— Improved prefetching. 
— High bandwidth low latency LLC architecture. 
— High bandwidth ring architecture of on-die interconnect. 


For additional information on Intel® Advanced Vector Extensions (AVX), see Section 5.13, “Intel® Advanced Vector 
Extensions (Intel® AVX)” and Chapter 14, “Programming with AVX, FMA and AVX2” in Intel® 64 and IA-32 Archi- 
tectures Software Developer’s Manual, Volume 1. 


2.2.7 SIMD Instructions 


Beginning with the Pentium II and Pentium with Intel MMX technology processor families, six extensions have been 
introduced into the Intel 64 and IA-32 architectures to perform single-instruction multiple-data (SIMD) operations. 
These extensions include the MMX technology, SSE extensions, SSE2 extensions, SSE3 extensions, Supplemental 
Streaming SIMD Extensions 3, and SSE4. Each of these extensions provides a group of instructions that perform 
SIMD operations on packed integer and/or packed floating-point data elements. 


SIMD integer operations can use the 64-bit MMX or the 128-bit XMM registers. SIMD floating-point operations use 
128-bit XMM registers. Figure 2-4 shows a summary of the various SIMD extensions (MMX technology, SSE, SSE2, 
SSE3, SSSE3, and SSE4), the data types they operate on, and how the data types are packed into MMX and XMM 
registers. 


The Intel MMX technology was introduced in the Pentium II and Pentium with MMX technology processor families. 
MMxX instructions perform SIMD operations on packed byte, word, or doubleword integers located in MMX registers. 
These instructions are useful in applications that operate on integer arrays and streams of integer data that lend 
themselves to SIMD processing. 


SSE extensions were introduced in the Pentium III processor family. SSE instructions operate on packed single- 
precision floating-point values contained in XMM registers and on packed integers contained in MMX registers. 
Several SSE instructions provide state management, cache control, and memory ordering operations. Other SSE 
instructions are targeted at applications that operate on arrays of single-precision floating-point data elements (3- 
D geometry, 3-D rendering, and video encoding and decoding applications). 


SSE2 extensions were introduced in Pentium 4 and Intel Xeon processors. SSE2 instructions operate on packed 
double-precision floating-point values contained in XMM registers and on packed integers contained in MMX and 
XMM registers. SSE2 integer instructions extend IA-32 SIMD operations by adding new 128-bit SIMD integer oper- 
ations and by expanding existing 64-bit SIMD integer operations to 128-bit XMM capability. SSE2 instructions also 
provide new cache control and memory ordering operations. 


SSE3 extensions were introduced with the Pentium 4 processor supporting Hyper-Threading Technology (built on 
90 nm process technology). SSE3 offers 13 instructions that accelerate performance of Streaming SIMD Extensions 
technology, Streaming SIMD Extensions 2 technology, and x87-FP math capabilities. 


SSSE3 extensions were introduced with the Intel Xeon processor 5100 series and Intel Core 2 processor family. 
SSSE3 offer 32 instructions to accelerate processing of SIMD integer data. 


SSE4 extensions offer 54 instructions. 47 of them are referred to as SSE4.1 instructions. SSE4.1 are introduced 
with Intel Xeon processor 5400 series and Intel Core 2 Extreme processor QX9650. The other 7 SSE4 instructions 
are referred to as SSE4.2 instructions. 
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AESNI and PCLMULQDQ introduce 7 new instructions. Six of them are primitives for accelerating algorithms based 
on AES encryption/decryption standard, referred to as AESNI. 


The PCLMULQDQ instruction accelerates general-purpose block encryption, which can perform carry-less multipli- 
cation for two binary numbers up to 64-bit wide. 


Intel 64 architecture allows four generations of 128-bit SIMD extensions to access up to 16 XMM registers. IA-32 
architecture provides 8 XMM registers. 


Intel® Advanced Vector Extensions offers comprehensive architectural enhancements over previous generations of 
Streaming SIMD Extensions. Intel AVX introduces the following architectural enhancements: 


¢ Support for 256-bit wide vectors and SIMD register set. 


° 256-bit floating-point instruction set enhancement with up to 2X performance gain relative to 128-bit 
Streaming SIMD extensions. 


¢ Instruction syntax support for generalized three-operand syntax to improve instruction programming flexibility 
and efficient encoding of new instruction extensions. 


¢ Enhancement of legacy 128-bit SIMD instruction extensions to support three operand syntax and to simplify 
compiler vectorization of high-level language expressions. 


¢ Support flexible deployment of 256-bit AVX code, 128-bit AVX code, legacy 128-bit code and scalar code. 


In addition to performance considerations, programmers should also be cognizant of the implications of VEX- 
encoded AVX instructions with the expectations of system software components that manage the processor state 
components enabled by XCRO. For additional information see Section 2.3.10.1, “Vector Length Transition and 
Programming Considerations” in Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A. 


See also: 
° Section 5.4, “MMX™ Instructions,” and Chapter 9, “Programming with Intel® MMX™ Technology” 


¢ Section 5.5, “SSE Instructions,” and Chapter 10, “Programming with Intel® Streaming SIMD Extensions 
(Intel® SSE)” 

¢ Section 5.6, “SSE2 Instructions,” and Chapter 11, “Programming with Intel® Streaming SIMD Extensions 2 
(Intel® SSE2)” 


* Section 5.7, “SSE3 Instructions”, Section 5.8, “Supplemental Streaming SIMD Extensions 3 (SSSE3) Instruc- 
tions”, Section 5.9, “SSE4 Instructions”, and Chapter 12, “Programming with Intel® SSE3, SSSE3, Intel® 
SSE4 and Intel® AESNI” 
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SIMD Extension Register Layout Data Type 


MMX Registers 
MMX Technology - SSSE3 TTT 8 Packed Byte Integers 


[TTT] 4 Packed Word Integers 
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Figure 2-4. SIMD Extensions, Register Layouts, and Data Types 


2.2.8 Intel® Hyper-Threading Technology 


Intel Hyper-Threading Technology (Intel HT Technology) was developed to improve the performance of IA-32 
processors when executing multi-threaded operating system and application code or single-threaded applications 
under multi-tasking environments. The technology enables a single physical processor to execute two or more 
separate code streams (threads) concurrently using shared execution resources. 


Intel HT Technology is one form of hardware multi-threading capability in IA-32 processor families. It differs from 
multi-processor capability using separate physically distinct packages with each physical processor package mated 
with a physical socket. Intel HT Technology provides hardware multi-threading capability with a single physical 
package by using shared execution resources in a processor core. 


Architecturally, an IA-32 processor that supports Intel HT Technology consists of two or more logical processors, 
each of which has its own IA-32 architectural state. Each logical processor consists of a full set of IA-32 data regis- 
ters, segment registers, control registers, debug registers, and most of the MSRs. Each also has its own advanced 
programmable interrupt controller (APIC). 


Figure 2-5 shows a comparison of a processor that supports Intel HT Technology (implemented with two logical 
processors) and a traditional dual processor system. 
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Figure 2-5. Comparison of an IA-32 Processor Supporting Hyper-Threading Technology and a Traditional Dual 
Processor System 


Unlike a traditional MP system configuration that uses two or more separate physical IA-32 processors, the logical 
processors in an IA-32 processor supporting Intel HT Technology share the core resources of the physical 
processor. This includes the execution engine and the system bus interface. After power up and initialization, each 
logical processor can be independently directed to execute a specified thread, interrupted, or halted. 


Intel HT Technology leverages the process and thread-level parallelism found in contemporary operating systems 
and high-performance applications by providing two or more logical processors on a single chip. This configuration 
allows two or more threads! to be executed simultaneously on each a physical processor. Each logical processor 
executes instructions from an application thread using the resources in the processor core. The core executes 
these threads concurrently, using out-of-order instruction scheduling to maximize the use of execution units during 
each clock cycle. 


2.2.8.1 Some Implementation Notes 


All Intel HT Technology configurations require: 

¢ A processor that supports Intel HT Technology 

¢ Achipset and BIOS that utilize the technology 

° Operating system optimizations 

See http://www. intel.com/products/ht/hyperthreading_more.htm for information. 


At the firmware (BIOS) level, the basic procedures to initialize the logical processors in a processor supporting Intel 
HT Technology are the same as those for a traditional DP or MP platform. The mechanisms that are described in the 
Multiprocessor Specification, Version 1.4 to power-up and initialize physical processors in an MP system also apply 
to logical processors in a processor that supports Intel HT Technology. 


An operating system designed to run on a traditional DP or MP platform may use CPUID to determine the presence 
of hardware multi-threading support feature and the number of logical processors they provide. 


Although existing operating system and application code should run correctly on a processor that supports Intel HT 
Technology, some code modifications are recommended to get the optimum benefit. These modifications are 
discussed in Chapter 7, “Multiple-Processor Management,” Inte/® 64 and IA-32 Architectures Software Devel- 
oper’s Manual, Volume 3A. 


1. In the remainder of this document, the term “thread” will be used as a general term for the terms “process” and “thread.” 
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2.2.9 Multi-Core Technology 


Multi-core technology is another form of hardware multi-threading capability in IA-32 processor families. Multi-core 
technology enhances hardware multi-threading capability by providing two or more execution cores in a physical 
package. 


The Intel Pentium processor Extreme Edition is the first member in the IA-32 processor family to introduce multi- 
core technology. The processor provides hardware multi-threading support with both two processor cores and Intel 
Hyper-Threading Technology. This means that the Intel Pentium processor Extreme Edition provides four logical 
processors in a physical package (two logical processors for each processor core). The Dual-Core Intel Xeon 
processor features multi-core, Intel Hyper-Threading Technology and supports multi-processor platforms. 


The Intel Pentium D processor also features multi-core technology. This processor provides hardware multi- 
threading support with two processor cores but does not offer Intel Hyper-Threading Technology. This means that 
the Intel Pentium D processor provides two logical processors in a physical package, with each logical processor 
owning the complete execution resources of a processor core. 


The Intel Core 2 processor family, Intel Xeon processor 3000 series, Intel Xeon processor 5100 series, and Intel 
Core Duo processor offer power-efficient multi-core technology. The processor contains two cores that share a 
smart second level cache. The Level 2 cache enables efficient data sharing between two cores to reduce memory 
traffic to the system bus. 
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Figure 2-6. Intel 64 and IA-32 Processors that Support Dual-Core 


The Pentium® dual-core processor is based on the same technology as the Intel Core 2 Duo processor family. 


The Intel Xeon processor 7300, 5300 and 3200 series, Intel Core 2 Extreme Quad-Core processor, and Intel Core 2 
Quad processors support Intel quad-core technology. The Quad-core Intel Xeon processors and the Quad-Core 
Intel Core 2 processor family are also in Figure 2-7. 
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Figure 2-7. Intel 64 Processors that Support Quad-Core 


Intel Core i7 processors support Intel quad-core technology, Intel HyperThreading Technology, provides Intel 
QuickPath interconnect link to the chipset and have integrated memory controller supporting three channel to 


DDR3 memory. 
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Figure 2-8. Intel Core i7 Processor 
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2.2.10 Intel® 64 Architecture 


Intel 64 architecture increases the linear address space for software to 64 bits and supports physical address space 
up to 52 bits. The technology also introduces a new operating mode referred to as IA-32e mode. 


IA-32e mode operates in one of two sub-modes: (1) compatibility mode enables a 64-bit operating system to run 
most legacy 32-bit software unmodified, (2) 64-bit mode enables a 64-bit operating system to run applications 
written to access 64-bit address space. 


In the 64-bit mode, applications may access: 

° 64-bit flat linear addressing 

* 8 additional general-purpose registers (GPRs) 

* 8 additional registers for streaming SIMD extensions (SSE, SSE2, SSE3 and SSSE3) 
°* 64-bit-wide GPRs and instruction pointers 

* uniform byte-register addressing 

¢ fast interrupt-prioritization mechanism 

* anew instruction-pointer relative-addressing mode 


An Intel 64 architecture processor supports existing IA-32 software because it is able to run all non-64-bit legacy 
modes supported by IA-32 architecture. Most existing IA-32 applications also run in compatibility mode. 


2.2.11 Intel® Virtualization Technology (Intel® VT) 


Intel® Virtualization Technology for Intel 64 and IA-32 architectures provide extensions that support virtualization. 
The extensions are referred to as Virtual Machine Extensions (VMX). An Intel 64 or IA-32 platform with VMX can 
function as multiple virtual systems (or virtual machines). Each virtual machine can run operating systems and 
applications in separate partitions. 


VMX also provides programming interface for a new layer of system software (called the Virtual Machine Monitor 
(VMM)) used to manage the operation of virtual machines. Information on VMX and on the programming of VMMs 
is in Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3C. 


Intel Core i7 processor provides the following enhancements to Intel Virtualization Technology: 

¢ Virtual processor ID (VPID) to reduce the cost of VMM managing transitions. 

¢ Extended page table (EPT) to reduce the number of transitions for VMM to manage memory virtualization. 
® Reduced latency of VM transitions. 


2.3 INTEL® 64 AND IA-32 PROCESSOR GENERATIONS 


In the mid-1960s, Intel cofounder and Chairman Emeritus Gordon Moore had this observation: “... the number of 
transistors that would be incorporated on a silicon die would double every 18 months for the next several years.” 
Over the past three and half decades, this prediction known as “Moore's Law” has continued to hold true. 


The computing power and the complexity (or roughly, the number of transistors per processor) of Intel architecture 
processors has grown in close relation to Moore's law. By taking advantage of new process technology and new 
microarchitecture designs, each new generation of IA-32 processors has demonstrated frequency-scaling head- 
room and new performance levels over the previous generation processors. 
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The key features of the Intel Pentium 4 processor, Intel Xeon processor, Intel Xeon processor MP, Pentium III 

processor, and Pentium Ill Xeon processor with advanced transfer cache are shown in Table 2-1. Older generation 
IA-32 processors, which do not employ on-die Level 2 cache, are shown in Table 2-2. 
Table 2-1. Key Features of Most Recent IA-32 Processors 


Intel Date Micro-architecture | Top-Bin Clock | Tran- Register System Max. On-Die 
Processor Intro- Fre-quency at | sistors Sizes Bus Band- | Extern. Caches@ 
duced Intro- width Addr. 
duction Space 
Intel Pentium | 2004 Intel Pentium M 2.00 GHz 140M GP: 32 3.2 GB/s 4GB L1:64 KB 
M Processor FPU: 80 L2: 2 MB 
Processor MMX: 64 
7553 XMM: 128 
Intel Core Duo | 2006 Improved Intel 2.16 GHz 152M GP: 32 5.3 GB/s 4GB L1:64 KB 
Processor Pentium M FPU: 80 L2: 2 MB 
T2600 Processor MMX: 64 (2MB Total) 
Microarchitecture; XMM: 128 
Dual Core; 
Intel Smart Cache, 
Advanced Thermal 
Manager 
Intel Atom 2008 Intel Atom 1.86 GHz - 47M GP: 32 Upto42 |4GB L1:56 KB4 
Processor Microarchitecture; | 800 MHz FPU: 80 GB/s L2: 512KB 
Z5xx series Intel Virtualization MMX: 64 
Technology. XMM: 128 
NOTES: 
1. The register size and external data bus size are given in bits. 
2. First level cache is denoted using the abbreviation L1, 2nd level cache is denoted as L2. The size 
of L1 includes the first-level data cache and the instruction cache where applicable, but 
does not include the trace cache. 
3. Intel processor numbers are not a measure of performance. Processor numbers differentiate 
features within each processor family, not across different processor families. 
See http://www. intel.com/products/processor_number for details. 
4. In Intel Atom Processor, the size of L1 instruction cache is 32 KBytes, L1 data cache is 24 KBytes. 
Table 2-2. Key Features of Most Recent Intel 64 Processors 
Intel Date Micro-architec- Highest Tran- Register System Max. On-Die 
Processor Intro- ture Processor sistors | Sizes Bus/QPI Extern. Caches 
duced Base Fre- Link Addr. 
quency at Speed Space 
Intro- 
duction 
64-bit Intel 2004 Intel NetBurst 3.60 GHz 125M _ | GP: 32,64 6.4 GB/s 64 GB 12K pop 
Xeon Microarchitecture; FPU: 80 Execution 
Processor Intel Hyper- MMxX: 64 Trace Cache; 
with 800 MHz Threading XMM: 128 16 KBL1; 
System Bus Technology; Intel 1MBL2 
64 Architecture 
64-bit Intel 2005 Intel NetBurst 3.33 GHz 675M GP: 32, 64 5.3GB/s' |1024GB_ | 12K yop 
Xeon Microarchitecture; FPU: 80 (1 TB) Execution 
Processor MP Intel Hyper- MMxX: 64 Trace Cache; 
with 8MB L3 Threading XMM: 128 16 KBL1; 
Technology; Intel 1MBL2, 
64 Architecture 8 MBL3 
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Table 2-2. Key Features of Most Recent Intel 64 Processors (Contd.) 


Intel Date Micro-architec- Highest Tran- Register System Max. On-Die 
Processor Intro- ture Processor sistors | Sizes Bus/QPI Extern. Caches 
duced Base Fre- Link Addr. 
quency at Speed Space 
Intro- 
duction 
Intel Pentium | 2005 Intel NetBurst 3.73 GHz 164M GP: 32, 64 8.5 GB/s 64 GB 12K pop 
4 Microarchitecture; FPU: 80 Execution 
Processor Intel Hyper- MMx: 64 Trace Cache; 
Extreme Threading XMM: 128 16 KBL1; 
Edition Technology; Intel 2MBL2 
Supporting 64 Architecture 
Hyper- 
Threading 
Technology 
Intel Pentium | 2005 Intel NetBurst 3.20 GHz 230M GP: 32, 64 6.4 GB/s 64 GB 12K yop 
Processor Microarchitecture; FPU: 80 Execution 
Extreme Intel Hyper- MMx: 64 Trace Cache; 
Edition 840 Threading XMM: 128 16 KBL1; 
Technology; Intel 1MBL2 
64 Architecture; (2MB Total) 
Dual-core @ 
Dual-Core Intel | 2005 Intel NetBurst 3.00 GHz 321M GP: 32, 64 6.4 GB/s 64 GB 12K pop 
Xeon Microarchitecture; FPU: 80 Execution 
Processor Intel Hyper- MMxX: 64 Trace Cache; 
7041 Threading XMM: 128 16 KBL1; 
Technology; Intel 2MB L2 
64 Architecture; (4MB Total) 
Dual-core 3 
Intel Pentium | 2005 Intel NetBurst 3.80 GHz 164M GP: 32, 64 6.4 GB/s 64 GB 12K yop 
4 Microarchitecture; FPU: 80 Execution 
Processor 672 Intel Hyper- MMx: 64 Trace Cache; 
Threading XMM: 128 16 KBL1; 
Technology; Intel 2MB L2 
64 Architecture; 
Intel Virtualization 
Technology. 
Intel Pentium | 2006 Intel NetBurst 3.46 GHz 376M GP: 32, 64 8.5 GB/s 64 GB 12K yop 
Processor Microarchitecture; FPU: 80 Execution 
Extreme Intel 64 MMxX: 64 Trace Cache; 
Edition 955 Architecture; Dual XMM: 128 16 KBL1; 
Core; 2MB L2 
Intel Virtualization (4MB Total) 
Technology. 
Intel Core 2 2006 Intel Core 2.93 GHz 291M GP: 32,64 8.5 GB/s 64 GB L1:64 KB 
Extreme Microarchitecture; FPU: 80 L2: 4MB 
Processor Dual Core; MMX: 64 (4MB Total) 
X6800 Intel 64 XMM: 128 
Architecture; 
Intel Virtualization 
Technology. 
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Table 2-2. Key Features of Most Recent Intel 64 Processors (Contd.) 


Intel Date Micro-architec- Highest Tran- Register System Max. On-Die 
Processor Intro- ture Processor sistors | Sizes Bus/QPI Extern. Caches 
duced Base Fre- Link Addr. 
quency at Speed Space 
Intro- 
duction 
Intel Xeon 2006 Intel Core 3.00 GHz 291M GP: 32, 64 10.6 GB/s | 64GB L1:64 KB 
Processor Microarchitecture; FPU: 80 L2: 4MB 
5160 Dual Core; MMX: 64 (4MB Total) 
Intel 64 XMM: 128 
Architecture; 
Intel Virtualization 
Technology. 
Intel Xeon 2006 Intel NetBurst 3.40 GHz 1.3B GP: 32, 64 12.8 GB/s | 64GB L1:64 KB 
Processor Microarchitecture; FPU: 80 L2: 1MB 
7140 Dual Core; MMX: 64 (2MB Total) 
Intel 64 XMM: 128 L3: 16 MB 
Architecture; (16MB Total) 
Intel Virtualization 
Technology. 
Intel Core 2 2006 Intel Core 2.66 GHz 582M GP: 32,64 8.5 GB/s 64 GB L1:64 KB 
Extreme Microarchitecture; FPU: 80 L2: 4MB 
Processor Quad Core; MMX: 64 (4MB Total) 
QX6700 Intel 64. XMM: 128 
Architecture; 
Intel Virtualization 
Technology. 
Quad-core 2006 Intel Core 2.66 GHz 582M GP: 32, 64 10.6 GB/s | 256 GB L1:64 KB 
Intel Xeon Microarchitecture; FPU: 80 L2: 4MB (8 
Processor Quad Core; MMX: 64 MB Total) 
5355 Intel 64. XMM: 128 
Architecture; 
Intel Virtualization 
Technology. 
Intel Core 2 2007 Intel Core 3.00 GHz 291M GP: 32, 64 10.6 GB/s | 64GB L1:64 KB 
Duo Processor Microarchitecture; FPU: 80 L2: 4MB 
€6850 Dual Core; MMX: 64 (4MB Total) 
Intel 64 XMM: 128 
Architecture; 
Intel Virtualization 
Technology; 
Intel Trusted 
Execution 
Technology 
Intel Xeon 2007 Intel Core 2.93 GHz 582M _ | GP: 32,64 8.5 GB/s 1024GB_ |L1:64KB 
Processor Microarchitecture; FPU: 80 L2: 4MB 
7350 Quad Core; MMX: 64 (8MB Total) 
Intel 64 XMM: 128 


Architecture; 


Intel Virtualization 
Technology. 
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Table 2-2. Key Features of Most Recent Intel 64 Processors (Contd.) 


Intel Date Micro-architec- Highest Tran- Register System Max. On-Die 
Processor Intro- ture Processor sistors | Sizes Bus/QPI Extern. Caches 
duced Base Fre- Link Addr. 
quency at Speed Space 
Intro- 
duction 
Intel Xeon 2007 Enhanced Intel 3.00 GHz 820M _ | GP: 32, 64 12.8 GB/s | 256GB L1:64 KB 
Processor Core FPU: 80 L2: 6MB 
5472 Microarchitecture; MMX: 64 (12MB Total) 
Quad Core; XMM: 128 
Intel 64 
Architecture; 
Intel Virtualization 
Technology. 
Intel Atom 2008 Intel Atom 2.0 - 1.60 47M GP: 32, 64 Up to 4.2 Up to L1:56 KB* 
Processor Microarchitecture; | GHz FPU: 80 GB/s 64GB L2:512KB 
Intel 64 MMx: 64 
Architecture; XMM: 128 
Intel Virtualization 
Technology. 
Intel Xeon 2008 Enhanced Intel 2.67 GHz 1.9B GP: 32, 64 8.5 GB/s 1024GB_ |L1:64KB 
Processor Core FPU: 80 L2: 3MB 
7460 Microarchitecture; MMX: 64 (SMB Total) 
Six Cores; XMM: 128 L3: 16MB 
Intel 64 
Architecture; 
Intel Virtualization 
Technology. 
Intel Atom 2008 Intel Atom 1.60 GHz 94M GP: 32, 64 Up to 4.2 Up to L1:56 KB? 
Processor 330 Microarchitecture; FPU: 80 GB/s 64GB L2:512KB 
Intel 64 MMx: 64 (1MB Total) 
Architecture; XMM: 128 
Dual core; 
Intel Virtualization 
Technology. 
Intel Core i7- 2008 Intel 3.20 GHz 731M _ | GP: 32,64 QPI: 6.4 64 GB L1:64 KB 
965 microarchitecture FPU: 80 GT/s; L2: 256KB 
Processor code name MMx: 64 Memory: L3: 8MB 
Extreme Nehalem; XMM: 128 25 GB/s 
Edition Quadcore; 
HyperThreading 
Technology; Intel 
QPI; Intel 64 


Architecture; 


Intel Virtualization 
Technology. 


2-24 Vol. 1 


INTEL® 64 AND IA-32 ARCHITECTURES 


Table 2-2. Key Features of Most Recent Intel 64 Processors (Contd.) 


Intel Date Micro-architec- Highest Tran- Register System Max. On-Die 
Processor Intro- ture Processor sistors | Sizes Bus/QPI Extern. Caches 
duced Base Fre- Link Addr. 
quency at Speed Space 
Intro- 
duction 


Intel Core i7- 2010 Intel Turbo Boost 2.66 GHz 383M | GP: 32,64 64 GB L1:64 KB 
620M Technology, Intel FPU: 80 L2: 256KB 
Processor microarchitecture MMX: 64 L3: 4MB 
code name XMM: 128 
Westmere; 
Dualcore; 
HyperThreading 
Technology; Intel 
64 Architecture; 
Intel Virtualization 
Technology., 
Integrated graphics 


Intel Xeon- 2010 Intel Turbo Boost 3.33 GHz 1.1B GP: 32, 64 QPI: 6.4 1 TB L1:64 KB 
Processor Technology, Intel FPU: 80 GT/s; 32 L2: 256KB 
5680 microarchitecture MMX: 64 GB/s L3:12MB 
code name XMM: 128 
Westmere; Six core; 
HyperThreading 
Technology; Intel 
64 Architecture; 


Intel Virtualization 
Technology. 


Intel Xeon- 2010 Intel Turbo Boost | 2.26 GHz 2.3B GP: 32, 64 QPI: 6.4 16 TB L1:64 KB 
Processor Technology, Intel FPU: 80 GT/s; L2: 256KB 
7560 microarchitecture MMX: 64 Memory: L3: 24MB 
code name XMM: 128 76 GB/s 
Nehalem; Eight 
core; 
HyperThreading 
Technology; Intel 
64 Architecture; 


Intel Virtualization 
Technology. 


Intel Core i7- | 2011 Intel Turbo Boost | 3.40 GHz 995M _ | GP: 32, 64 DMI: 5 64 GB L1:64 KB 
2600K Technology, Intel FPU: 80 GT/s; L2: 256KB 
Processor microarchitecture MMx: 64 Memory: L3:8MB 

code name Sandy XMM: 128 21 GB/s 
Bridge; Four core; YMM: 256 
HyperThreading 
Technology; Intel 
64 Architecture; 


Intel Virtualization 
Technology., 
Processor graphics, 
Quicksync Video 
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Table 2-2. Key Features of Most Recent Intel 64 Processors (Contd.) 


Intel Date Micro-architec- Highest Tran- Register System Max. On-Die 
Processor Intro- ture Processor sistors | Sizes Bus/QPI Extern. Caches 
duced Base Fre- Link Addr. 
quency at Speed Space 
Intro- 
duction 
Intel Xeon- 2011 Intel Turbo Boost 3.50 GHz GP: 32, 64 DMI: 5 1TB L1:64 KB 
Processor E3- Technology, Intel FPU: 80 GT/s; L2: 256KB 
1280 microarchitecture MMx: 64 Memory: L3: 8MB 
code name Sandy XMM: 128 21 GB/s 
Bridge; Four core; YMM: 256 
HyperThreading 
Technology; Intel 
64 Architecture; 
Intel Virtualization 
Technology. 
Intel Xeon- 2011 Intel Turbo Boost | 2.40 GHz 2.2B GP: 32, 64 QPI: 6.4 16 TB L1:64 KB 
Processor E7- Technology, Intel FPU: 80 GT/s; L2: 256KB 
8870 microarchitecture MMxX: 64 Memory: L3: 30MB 
code name XMM: 128 102 GB/s 


Westmere; Ten 
core; 
HyperThreading 
Technology; Intel 
64 Architecture; 


Intel Virtualization 
Technology. 


NOTES: 


1. The 64-bit Intel Xeon Processor MP with an 8-MByte L3 supports a multi-processor platform with a dual system bus; this creates a 
platform bandwidth with 10.6 GBytes. 
2. In Intel Pentium Processor Extreme Edition 840, the size of on-die cache is listed for each core. The total size of L2 in the physical 
package in 2 MBytes. 
3. In Dual-Core Intel Xeon Processor 7041, the size of on-die cache is listed for each core. The total size of L2 in the physical package in 


4 MBytes. 


4. In Intel Atom Processor, the size of L1 instruction cache is 32 KBytes, L1 data cache is 24 KBytes. 
5. In Intel Atom Processor, the size of L1 instruction cache is 32 KBytes, L1 data cache is 24 KBytes. 
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Table 2-3. Key Features of Previous Generations of IA-32 Processors 


Intel Date Max. Clock Tran- Register Ext. Data Max. Caches 
Processor Intro- Frequency/ sistors Sizes! Bus Size@ Extern. 
duced Technology at Addr. 
Introduction Space 
8086 1978 8 MHz 29K 16 GP 16 1 MB None 
Intel 286 1982 12.5 MHz 134K 16 GP 16 16 MB Note 3 
Intel386 DX 1985 20 MHz 275K 32 GP 32 4 GB Note 3 
Processor 
Intel486 DX 1989 25 MHz 1.2M 32 GP 32 4 GB L1:8 KB 
Processor 80 FPU 
Pentium Processor 1993 60 MHz 3.1M 32 GP 64 4 GB L1:16 KB 
80 FPU 
Pentium Pro 1995 200 MHz 5.5M 32 GP 64 64 GB L1: 16 KB 
Processor 80 FPU L2: 256 KB or 
512 KB 
Pentium II Processor | 1997 266 MHz 7M 32 GP 64 64 GB L1: 32 KB 
80 FPU L2: 256 KB or 
64 MMX 512 KB 
Pentium Ill Processor | 1999 500 MHz 8.2 M 32 GP 64 64 GB L1:32 KB 
80 FPU L2:512 KB 
64 MMX 
128 XMM 
Pentium Ill and 1999 700 MHz 28M 32 GP 64 64 GB L1: 32 KB 
Pentium Ill Xeon 80 FPU L2: 256 KB 
Processors 64 MMX 
128 XMM 
Pentium 4 Processor | 2000 1.50 GHz, Intel 42M 32 GP 64 64 GB 12K yop 
NetBurst 80 FPU Execution 
Microarchitecture 64 MMX Trace Cache; 
128 XMM L1: 8KB 
L2: 256 KB 
Intel Xeon Processor | 2001 1.70 GHz, Intel 42M 32 GP 64 64 GB 12K yop 
NetBurst 80 FPU Execution 
Microarchitecture 64 MMX Trace Cache; 
128 XMM L1: 8KB 
L2:512KB 
Intel Xeon Processor | 2002 2.20 GHz, Intel 55M 32 GP 64 64 GB 12K yop 
NetBurst 80 FPU Execution 
Microarchitecture, 64 MMX Trace Cache; 
HyperThreading 128 XMM L1: 8KB 
Technology L2:512KB 
Pentium M Processor | 2003 1.60 GHz, Intel 77M 32 GP 64 4 GB L1: 64KB 
NetBurst 80 FPU L2: 1 MB 
Microarchitecture 64 MMX 
128 XMM 
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Table 2-3. Key Features of Previous Generations of IA-32 Processors (Contd.) 


Intel Pentium 4 2004 3.40 GHz, Intel 125M 32 GP 64 64 GB 12K yop 
Processor NetBurst 80 FPU Execution 
Supporting Hyper- Microarchitecture, 64 MMX Trace Cache; 
Threading HyperThreading 128 XMM L1: 16KB 
Technology at 90 nm Technology L2:1 MB 
process 

NOTE: 


1. The register size and external data bus size are given in bits. Note also that each 32-bit general-purpose (GP) registers can be 
addressed as an 8- or a 16-bit data registers in all of the processors. 


2. Internal data paths are 2 to 4 times wider than the external data bus for each processor. 


2.4 PROPOSED REMOVAL OF INTEL INSTRUCTION SET ARCHITECTURE AND 


FEATURES FROM UPCOMING PRODUCTS 


This section lists Intel Instruction Set Architecture (ISA) and features that Intel plans to remove from select prod- 
ucts starting from a specific year. 


Table 2-4. Proposed Intel ISA and Features Removal List 
Year of Removal 


Intel ISA/Feature 
NA NA 


2.5 INTEL INSTRUCTION SET ARCHITECTURE AND FEATURES REMOVED 


This section lists Intel ISA and features that Intel has already removed for select upcoming products. All sections 
relevant to the removed features will be identified as such and may be moved to an archived section in future 
Intel® 64 and IA-32 Architectures Software Developer's Manual releases. 


Table 2-5. Intel ISA and Features Removal List 


Intel ISA/Feature Year of Removal 
Intel? Memory Protection Extensions (Intel? MPX) 2019 onwards 
MSR_TEST_CTRL, bit 31 (MSR address 33H) 2019 onwards 
Hardware Lock Elision (HLE) 2019 onwards 
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CHAPTER 3 
BASIC EXECUTION ENVIRONMENT 


This chapter describes the basic execution environment of an Intel 64 or IA-32 processor as seen by assembly- 
language programmers. It describes how the processor executes instructions and how it stores and manipulates 
data. The execution environment described here includes memory (the address space), general-purpose data 
registers, segment registers, the flag register, and the instruction pointer register. 


3.1 MODES OF OPERATION 


The IA-32 architecture supports three basic operating modes: protected mode, real-address mode, and system 
management mode. The operating mode determines which instructions and architectural features are accessible: 


¢ Protected mode — This mode is the native state of the processor. Among the capabilities of protected mode 
is the ability to directly execute “real-address mode” 8086 software in a protected, multi-tasking environment. 
This feature is called virtual-8086 mode, although it is not actually a processor mode. Virtual-8086 mode is 
actually a protected mode attribute that can be enabled for any task. 


° Real-address mode — This mode implements the programming environment of the Intel 8086 processor with 
extensions (such as the ability to switch to protected or system management mode). The processor is placed in 
real-address mode following power-up or a reset. 


¢ System management mode (SMM) — This mode provides an operating system or executive with a 
transparent mechanism for implementing platform-specific functions such as power management and system 
security. The processor enters SMM when the external SMM interrupt pin (SMI#) is activated or an SMI is 
received from the advanced programmable interrupt controller (APIC). 


In SMM, the processor switches to a separate address space while saving the basic context of the currently 
running program or task. SMM-specific code may then be executed transparently. Upon returning from SMM, 
the processor is placed back into its state prior to the system management interrupt. SMM was introduced with 
the Intel386" SL and Intel486™ SL processors and became a standard IA-32 feature with the Pentium 
processor family. 


3.1.1 Intel® 64 Architecture 


Intel 64 architecture adds IA-32e mode. IA-32e mode has two sub-modes. 
These are: 


¢ Compatibility mode (sub-mode of IA-32e mode) — Compatibility mode permits most legacy 16-bit and 
32-bit applications to run without re-compilation under a 64-bit operating system. For brevity, the compatibility 
sub-mode is referred to as compatibility mode in IA-32 architecture. The execution environment of compati- 
bility mode is the same as described in Section 3.2. Compatibility mode also supports all of the privilege levels 
that are supported in 64-bit and protected modes. Legacy applications that run in Virtual 8086 mode or use 
hardware task management will not work in this mode. 


Compatibility mode is enabled by the operating system (OS) on a code segment basis. This means that a single 
64-bit OS can support 64-bit applications running in 64-bit mode and support legacy 32-bit applications (not 
recompiled for 64-bits) running in compatibility mode. 


Compatibility mode is similar to 32-bit protected mode. Applications access only the first 4 GByte of linear- 
address space. Compatibility mode uses 16-bit and 32-bit address and operand sizes. Like protected mode, this 
mode allows applications to access physical memory greater than 4 GByte using PAE (Physical Address Exten- 
sions). 


° 64-bit mode (sub-mode of IA-32e mode) — This mode enables a 64-bit operating system to run applica- 
tions written to access 64-bit linear address space. For brevity, the 64-bit sub-mode is referred to as 64-bit 
mode in IA-32 architecture. 
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64-bit mode extends the number of general purpose registers and SIMD extension registers from 8 to 16. 
General purpose registers are widened to 64 bits. The mode also introduces a new opcode prefix (REX) to 
access the register extensions. See Section 3.2.1 for a detailed description. 


64-bit mode is enabled by the operating system on a code-segment basis. Its default address size is 64 bits and 
its default operand size is 32 bits. The default operand size can be overridden on an instruction-by-instruction 
basis using a REX opcode prefix in conjunction with an operand size override prefix. 


REX prefixes allow a 64-bit operand to be specified when operating in 64-bit mode. By using this mechanism, 
many existing instructions have been promoted to allow the use of 64-bit registers and 64-bit addresses. 


3.2 OVERVIEW OF THE BASIC EXECUTION ENVIRONMENT 


Any program or task running on an IA-32 processor is given a set of resources for executing instructions and for 
storing code, data, and state information. These resources (described briefly in the following paragraphs and 
shown in Figure 3-1) make up the basic execution environment for an IA-32 processor. 


An Intel 64 processor supports the basic execution environment of an IA-32 processor, and a similar environment 
under IA-32e mode that can execute 64-bit programs (64-bit sub-mode) and 32-bit programs (compatibility sub- 
mode). 


The basic execution environment is used jointly by the application programs and the operating system or executive 
running on the processor. 


¢ Address space — Any task or program running on an IA-32 processor can address a linear address space of 
up to 4 GBytes (232 bytes) and a physical address space of up to 64 GBytes (27° bytes). See Section 3.3.6, 
“Extended Physical Addressing in Protected Mode,” for more information about addressing an address space 
greater than 4 GBytes. 


¢ Basic program execution registers — The eight general-purpose registers, the six segment registers, the 
EFLAGS register, and the EIP (instruction pointer) register comprise a basic execution environment in which to 
execute a set of general-purpose instructions. These instructions perform basic integer arithmetic on byte, 
word, and doubleword integers, handle program flow control, operate on bit and byte strings, and address 
memory. See Section 3.4, “Basic Program Execution Registers,” for more information about these registers. 


°* x87 FPU registers — The eight x87 FPU data registers, the x87 FPU control register, the status register, the 
x87 FPU instruction pointer register, the x87 FPU operand (data) pointer register, the x87 FPU tag register, and 
the x87 FPU opcode register provide an execution environment for operating on single-precision, double- 
precision, and double extended-precision floating-point values, word integers, doubleword integers, quadword 
integers, and binary coded decimal (BCD) values. See Section 8.1, “x87 FPU Execution Environment,” for more 
information about these registers. 


° MMxX registers — The eight MMX registers support execution of single-instruction, multiple-data (SIMD) 
operations on 64-bit packed byte, word, and doubleword integers. See Section 9.2, “The MMX Technology 
Programming Environment,” for more information about these registers. 


° XMM registers — The eight XMM data registers and the MXCSR register support execution of SIMD operations 
on 128-bit packed single-precision and double-precision floating-point values and on 128-bit packed byte, 
word, doubleword, and quadword integers. See Section 10.2, “SSE Programming Environment,” for more 
information about these registers. 


° YMM registers — The YMM data registers support execution of 256-bit SIMD operations on 256-bit packed 
single-precision and double-precision floating-point values and on 256-bit packed byte, word, doubleword, and 
quadword integers. 


° Bounds registers — Each of the BNDO-BND3 register stores the lower and upper bounds (64 bits each) 
associated with the pointer to a memory buffer. They support execution of the Intel MPX instructions. 


¢ BNDCFGU and BNDSTATUS— BNDCFGU configures user mode MPX operations on bounds checking. 
BNDSTATUS provides additional information on the #BR caused by an MPX operation. 
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Figure 3-1. IA-32 Basic Execution Environment for Non-64-bit Modes 
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Stack — To support procedure or subroutine calls and the passing of parameters between procedures or 
subroutines, a stack and stack management resources are included in the execution environment. The stack 
(not shown in Figure 3-1) is located in memory. See Section 6.2, “Stacks,” for more information about stack 
structure. 


In addition to the resources provided in the basic execution environment, the IA-32 architecture provides the 
following resources as part of its system-level architecture. They provide extensive support for operating-system 
and system-development software. Except for the I/O ports, the system resources are described in detail in the 
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 3A & 3B. 


I/O ports — The IA-32 architecture supports a transfers of data to and from input/output (I/O) ports. See 
Chapter 19, “Input/Output,” in this volume. 


Control registers — The five control registers (CRO through CR4) determine the operating mode of the 
processor and the characteristics of the currently executing task. See Chapter 2, “System Architecture 
Overview,” in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. 


Memory management registers — The GDTR, IDTR, task register, and LDTR specify the locations of data 
structures used in protected mode memory management. See Chapter 2, “System Architecture Overview,” in 
the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. 


Debug registers — The debug registers (DRO through DR7) control and allow monitoring of the processor's 
debugging operations. See in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3B. 


Memory type range registers (MTRRs) — The MTRRs are used to assign memory types to regions of 
memory. See the sections on MTRRs in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 
Volumes 3A & 3B. 


Model-specific registers (MSRs) — The processor provides a variety of model-specific registers that are 
used to control and report on processor performance. Virtually all MSRs handle system related functions and 
are not accessible to an application program. One exception to this rule is the time-stamp counter. The MSRs 
are described in Chapter 2, “Model-Specific Registers (MSRs)” of the Inte/® 64 and IA-32 Architectures 
Software Developer’s Manual, Volume 4. 


Machine check registers — The machine check registers consist of a set of control, status, and error- 
reporting MSRs that are used to detect and report on hardware (machine) errors. See Chapter 15, “Machine- 
Check Architecture,” of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. 


Performance monitoring counters — The performance monitoring counters allow processor performance 
events to be monitored. See Chapter 18, “Performance Monitoring,” in the Inte/® 64 and IA-32 Architectures 
Software Developer’s Manual, Volume 3B. 


The remainder of this chapter describes the organization of memory and the address space, the basic program 
execution registers, and addressing modes. Refer to the following chapters in this volume for descriptions of the 
other program execution resources shown in Figure 3-1: 


x87 FPU registers — See Chapter 8, “Programming with the x87 FPU.” 
MMX Registers — See Chapter 9, “Programming with Intel® MMX™ Technology.” 


XMM registers — See Chapter 10, “Programming with Intel® Streaming SIMD Extensions (Intel® SSE),” 
Chapter 11, “Programming with Intel® Streaming SIMD Extensions 2 (Intel® SSE2),” and Chapter 12, 
“Programming with Intel® SSE3, SSSE3, Intel® SSE4 and Intel® AESNI.” 


YMM registers — See Chapter 14, “Programming with AVX, FMA and AVX2”. 


BND registers, BNDCFGU, BNDSTATUS — See Chapter 13, “Managing State Using the XSAVE Feature Set,” 
and Chapter 17, “Intel® MPX”. 


Stack implementation and procedure calls — See Chapter 6, “Procedure Calls, Interrupts, and Exceptions.” 
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3.2.1 64-Bit Mode Execution Environment 


The execution environment for 64-bit mode is similar to that described in Section 3.2. The following paragraphs 
describe the differences that apply. 


Address space — A task or program running in 64-bit mode on an IA-32 processor can address linear address 
space of up to 2° bytes (subject to the canonical addressing requirement described in Section 3.3.7.1) and 
physical address space of up to 2°2 bytes. Software can query CPUID for the physical address size supported 
by a processor. 


Basic program execution registers — The number of general-purpose registers (GPRs) available is 16. 
GPRs are 64-bits wide and they support operations on byte, word, doubleword and quadword integers. 
Accessing byte registers is done uniformly to the lowest 8 bits. The instruction pointer register becomes 64 bits. 
The EFLAGS register is extended to 64 bits wide, and is referred to as the RFLAGS register. The upper 32 bits 
of RFLAGS is reserved. The lower 32 bits of RFLAGS is the same as EFLAGS. See Figure 3-2. 


XMM registers — There are 16 XMM data registers for SIMD operations. See Section 10.2, “SSE Programming 
Environment,” for more information about these registers. 


YMM registers — There are 16 YMM data registers for SIMD operations. See Chapter 14, “Programming with 
AVX, FMA and AVX2” for more information about these registers. 


BND registers, BNDCFGU, BNDSTATUS — See Chapter 13, “Managing State Using the XSAVE Feature Set,” 
and Chapter 17, “Intel® MPX”. 


Stack — The stack pointer size is 64 bits. Stack size is not controlled by a bit in the SS descriptor (as it is in 
non-64-bit modes) nor can the pointer size be overridden by an instruction prefix. 

Control registers — Control registers expand to 64 bits. A new control register (the task priority register: CR8 
or TPR) has been added. See Chapter 2, “Intel® 64 and IA-32 Architectures,” in this volume. 


Debug registers — Debug registers expand to 64 bits. See Chapter 17, “Debug, Branch Profile, TSC, and 
Intel® Resource Director Technology (Intel® RDT) Features,” in the Intel® 64 and IA-32 Architectures Software 
Developer’s Manual, Volume 3A. 
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* Descriptor table registers — The global descriptor table register (GDTR) and interrupt descriptor table 
register (IDTR) expand to 10 bytes so that they can hold a full 64-bit base address. The local descriptor table 
register (LDTR) and the task register (TR) also expand to hold a full 64-bit base address. 
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32-bits MXCSR Register 
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Registers YMM Registers 


Figure 3-2. 64-Bit Mode Execution Environment 


3.3 MEMORY ORGANIZATION 


The memory that the processor addresses on its bus is called physical memory. Physical memory is organized as 
a sequence of 8-bit bytes. Each byte is assigned a unique address, called a physical address. The physical 
address space ranges from zero to a maximum of 23° -1 (64 GBytes) if the processor does not support Intel 
64 architecture. Intel 64 architecture introduces a set of changes in physical and linear address space; these 
are described in Section 3.3.3, Section 3.3.4, and Section 3.3.7. 
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Virtually any operating system or executive designed to work with an IA-32 or Intel 64 processor will use the 
processor’s memory management facilities to access memory. These facilities provide features such as segmenta- 
tion and paging, which allow memory to be managed efficiently and reliably. Memory management is described in 
detail in Chapter 3, “Protected-Mode Memory Management,” in the Inte/® 64 and IA-32 Architectures Software 
Developer’s Manual, Volume 3A. The following paragraphs describe the basic methods of addressing memory when 
memory management is used. 


3.3.1 IA-32 Memory Models 


When employing the processor’s memory management facilities, programs do not directly address physical 
memory. Instead, they access memory using one of three memory models: flat, segmented, or real address mode: 


Flat memory model — Memory appears to a program as a single, continuous address space (Figure 3-3). This 
space is called a linear address space. Code, data, and stacks are all contained in this address space. Linear 
address space is byte addressable, with addresses running contiguously from 0 to 22 - 1 (if not in 64-bit 
mode). An address for any byte in linear address space is called a linear address. 


Segmented memory model — Memory appears to a program as a group of independent address spaces 
called segments. Code, data, and stacks are typically contained in separate segments. To address a byte ina 
segment, a program issues a logical address. This consists of a segment selector and an offset (logical 
addresses are often referred to as far pointers). The segment selector identifies the segment to be accessed 
and the offset identifies a byte in the address space of the segment. Programs running on an IA-32 processor 
can address up to 16,383 segments of different sizes and types, and each segment can be as large as 23 
bytes. 


Internally, all the segments that are defined for a system are mapped into the processor’s linear address space. 
To access a memory location, the processor thus translates each logical address into a linear address. This 
translation is transparent to the application program. 


The primary reason for using segmented memory is to increase the reliability of programs and systems. For 
example, placing a program's stack in a separate segment prevents the stack from growing into the code or 
data space and overwriting instructions or data, respectively. 


Real-address mode memory model — This is the memory model for the Intel 8086 processor. It is 
supported to provide compatibility with existing programs written to run on the Intel 8086 processor. The real- 
address mode uses a specific implementation of segmented memory in which the linear address space for the 
program and the operating system/executive consists of an array of segments of up to 64 KBytes in size each. 
The maximum size of the linear address space in real-address mode is 22° bytes. 


See also: Chapter 19, “8086 Emulation,” Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 3B. 
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Figure 3-3. Three Memory Management Models 


3.3.2 Paging and Virtual Memory 


With the flat or the segmented memory model, linear address space is mapped into the processor’s physical 
address space either directly or through paging. When using direct mapping (paging disabled), each linear address 
has a one-to-one correspondence with a physical address. Linear addresses are sent out on the processor’s address 
lines without translation. 


When using the IA-32 architecture’s paging mechanism (paging enabled), linear address space is divided into 
pages which are mapped to virtual memory. The pages of virtual memory are then mapped as needed into physical 
memory. When an operating system or executive uses paging, the paging mechanism is transparent to an applica- 
tion program. All that the application sees is linear address space. 

In addition, IA-32 architecture’s paging mechanism includes extensions that support: 

¢ Physical Address Extensions (PAE) to address physical address space greater than 4 GBytes. 

° Page Size Extensions (PSE) to map linear address to physical address in 4-MBytes pages. 


See also: Chapter 3, “Protected-Mode Memory Management,” in the Inte/® 64 and IA-32 Architectures Software 
Developer’s Manual, Volume 3A. 


3.3.3 Memory Organization in 64-Bit Mode 


Intel 64 architecture supports physical address space greater than 64 GBytes; the actual physical address size of 
IA-32 processors is implementation specific. In 64-bit mode, there is architectural support for 64-bit linear address 
space. However, processors supporting Intel 64 architecture may implement less than 64-bits (see Section 
3.3.7.1). The linear address space is mapped into the processor physical address space through the PAE paging 
mechanism. 
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3.3.4 Modes of Operation vs. Memory Model 


When writing code for an IA-32 or Intel 64 processor, a programmer needs to know the operating mode the 
processor is going to be in when executing the code and the memory model being used. The relationship between 
operating modes and memory models is as follows: 


¢ Protected mode — When in protected mode, the processor can use any of the memory models described in 
this section. (The real-addressing mode memory model is ordinarily used only when the processor is in the 
virtual-8086 mode.) The memory model used depends on the design of the operating system or executive. 
When multitasking is implemented, individual tasks can use different memory models. 


° Real-address mode — When in real-address mode, the processor only supports the real-address mode 
memory model. 


¢ System management mode — When in SMM, the processor switches to a separate address space, called the 
system management RAM (SMRAM). The memory model used to address bytes in this address space is similar 
to the real-address mode model. See Chapter 30, “System Management Mode,” in the Inte/® 64 and IA-32 
Architectures Software Developer’s Manual, Volume 3C, for more information on the memory model used in 
SMM. 


¢ Compatibility mode — Software that needs to run in compatibility mode should observe the same memory 
model as those targeted to run in 32-bit protected mode. The effect of segmentation is the same as it is in 32- 
bit protected mode semantics. 


° 64-bit mode — Segmentation is generally (but not completely) disabled, creating a flat 64-bit linear-address 
space. Specifically, the processor treats the segment base of CS, DS, ES, and SS as zero in 64-bit mode (this 
makes a linear address equal an effective address). Segmented and real address modes are not available in 64- 
bit mode. 


3.3.5 32-Bit and 16-Bit Address and Operand Sizes 


IA-32 processors in protected mode can be configured for 32-bit or 16-bit address and operand sizes. With 32-bit 
address and operand sizes, the maximum linear address or segment offset is FFFFFFFFH (222-1); operand sizes are 
typically 8 bits or 32 bits. With 16-bit address and operand sizes, the maximum linear address or segment offset is 
FFFFH (21-1); operand sizes are typically 8 bits or 16 bits. 


When using 32-bit addressing, a logical address (or far pointer) consists of a 16-bit segment selector and a 32-bit 
offset; when using 16-bit addressing, an address consists of a 16-bit segment selector and a 16-bit offset. 


Instruction prefixes allow temporary overrides of the default address and/or operand sizes from within a program. 


When operating in protected mode, the segment descriptor for the currently executing code segment defines the 
default address and operand size. A segment descriptor is a system data structure not normally visible to applica- 
tion code. Assembler directives allow the default addressing and operand size to be chosen for a program. The 
assembler and other tools then set up the segment descriptor for the code segment appropriately. 


When operating in real-address mode, the default addressing and operand size is 16 bits. An address-size override 
can be used in real-address mode to enable 32-bit addressing. However, the maximum allowable 32-bit linear 
address is still OOOFFFFFH (229-1). 


3.3.6 Extended Physical Addressing in Protected Mode 


Beginning with P6 family processors, the IA-32 architecture supports addressing of up to 64 GBytes (27° bytes) of 
physical memory. A program or task could not address locations in this address space directly. Instead, it 
addresses individual linear address spaces of up to 4 GBytes that mapped to 64-GByte physical address space 
through a virtual memory management mechanism. Using this mechanism, an operating system can enable a 
program to switch 4-GByte linear address spaces within 64-GByte physical address space. 


The use of extended physical addressing requires the processor to operate in protected mode and the operating 
system to provide a virtual memory management system. See “36-Bit Physical Addressing Using the PAE Paging 
Mechanism” in Chapter 3, “Protected-Mode Memory Management,” of the Inte/® 64 and IA-32 Architectures Soft- 
ware Developer’s Manual, Volume 3A. 


Vol.1 3-9 


BASIC EXECUTION ENVIRONMENT 


3.3.7 Address Calculations in 64-Bit Mode 


In most cases, 64-bit mode uses flat address space for code, data, and stacks. In 64-bit mode (if there is no 
address-size override), the size of effective address calculations is 64 bits. An effective-address calculation uses a 
64-bit base and index registers and sign-extend displacements to 64 bits. 


In the flat address space of 64-bit mode, linear addresses are equal to effective addresses because the base 
address is zero. In the event that FS or GS segments are used with a non-zero base, this rule does not hold. In 64- 
bit mode, the effective address components are added and the effective address is truncated (See for example the 
instruction LEA) before adding the full 64-bit segment base. The base is never truncated, regardless of addressing 
mode in 64-bit mode. 


The instruction pointer is extended to 64 bits to support 64-bit code offsets. The 64-bit instruction pointer is called 
the RIP. Table 3-1 shows the relationship between RIP, EIP, and IP. 


Table 3-1. Instruction Pointer Sizes 


Bits 63:32 Bits 31:16 Bits 15:0 
16-bit instruction pointer Not Modified IP 
32-bit instruction pointer Zero Extension EIP 
64-bit instruction pointer RIP 


Generally, displacements and immediates in 64-bit mode are not extended to 64 bits. They are still limited to 32 
bits and sign-extended during effective-address calculations. In 64-bit mode, however, support is provided for 64- 
bit displacement and immediate forms of the MOV instruction. 


All 16-bit and 32-bit address calculations are zero-extended in IA-32e mode to form 64-bit addresses. Address 
calculations are first truncated to the effective address size of the current mode (64-bit mode or compatibility 
mode), as overridden by any address-size prefix. The result is then zero-extended to the full 64-bit address width. 
Because of this, 16-bit and 32-bit applications running in compatibility mode can access only the low 4 GBytes of 
the 64-bit mode effective addresses. Likewise, a 32-bit address generated in 64-bit mode can access only the low 
4 GBytes of the 64-bit mode effective addresses. 


3.3.7.1 Canonical Addressing 


In 64-bit mode, an address is considered to be in canonical form if address bits 63 through to the most-significant 
implemented bit by the microarchitecture are set to either all ones or all zeros. 


Intel 64 architecture defines a 64-bit linear address. Implementations can support less. The first implementation of 
IA-32 processors with Intel 64 architecture supports a 48-bit linear address. This means a canonical address must 
have bits 63 through 48 set to zeros or ones (depending on whether bit 47 is a zero or one). 


Although implementations may not use all 64 bits of the linear address, they should check bits 63 through the 

most-significant implemented bit to see if the address is in canonical form. If a linear-memory reference is not in 
canonical form, the implementation should generate an exception. In most cases, a general-protection exception 
(#GP) is generated. However, in the case of explicit or implied stack references, a stack fault (#SS) is generated. 


Instructions that have implied stack references, by default, use the SS segment register. These include PUSH/POP- 
related instructions and instructions using RSP/RBP as base registers. In these cases, the canonical fault is #SS. 


If an instruction uses base registers RSP/RBP and uses a segment override prefix to specify a non-SS segment, a 

canonical fault generates a #GP (instead of an #SS). In 64-bit mode, only FS and GS segment-overrides are appli- 
cable in this situation. Other segment override prefixes (CS, DS, ES and SS) are ignored. Note that this also means 
that an SS segment-override applied to a “non-stack” register reference is ignored. Such a sequence still produces 
a #GP for a canonical fault (and not an #SS). 


3.4 BASIC PROGRAM EXECUTION REGISTERS 


IA-32 architecture provides 16 basic program execution registers for use in general system and application 
programing (see Figure 3-4). These registers can be grouped as follows: 
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¢ General-purpose registers. These eight registers are available for storing operands and pointers. 
° Segment registers. These registers hold up to six segment selectors. 


¢ EFLAGS (program status and control) register. The EFLAGS register report on the status of the program 
being executed and allows limited (application-program level) control of the processor. 


¢ IP (instruction pointer) register. The EIP register contains a 32-bit pointer to the next instruction to be 
executed. 


3.4.1 General-Purpose Registers 


The 32-bit general-purpose registers EAX, EBX, ECX, EDX, ESI, EDI, EBP, and ESP are provided for holding the 
following items: 

°® Operands for logical and arithmetic operations 

* Operands for address calculations 

¢ Memory pointers 

Although all of these registers are available for general storage of operands, results, and pointers, caution should 


be used when referencing the ESP register. The ESP register holds the stack pointer and as a general rule should 
not be used for another purpose. 


Many instructions assign specific registers to hold operands. For example, string instructions use the contents of 

the ECX, ESI, and EDI registers as operands. When using a segmented memory model, some instructions assume 
that pointers in certain registers are relative to specific segments. For instance, some instructions assume that a 

pointer in the EBX register points to a memory location in the DS segment. 
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Figure 3-4. General System and Application Programming Registers 
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The special uses of general-purpose registers by instructions are described in Chapter 5, “Instruction Set 
Summary,” in this volume. See also: Chapter 3, Chapter 4 and Chapter 5 of Inte/® 64 and IA-32 Architectures Soft- 
ware Developer’s Manual, Volumes 2A, 2B & 2C. The following is a summary of special uses: 


° EAX — Accumulator for operands and results data 

° EBX — Pointer to data in the DS segment 

¢ ECX — Counter for string and loop operations 

¢ EDX — I/O pointer 

¢ ESI — Pointer to data in the segment pointed to by the DS register; source pointer for string operations 


¢ EDI — Pointer to data (or destination) in the segment pointed to by the ES register; destination pointer for 
string operations 


¢ ESP — Stack pointer (in the SS segment) 
¢ EBP — Pointer to data on the stack (in the SS segment) 


As shown in Figure 3-5, the lower 16 bits of the general-purpose registers map directly to the register set found in 
the 8086 and Intel 286 processors and can be referenced with the names AX, BX, CX, DX, BP, SI, DI, and SP. Each 
of the lower two bytes of the EAX, EBX, ECX, and EDX registers can be referenced by the names AH, BH, CH, and 
DH (high bytes) and AL, BL, CL, and DL (low bytes). 


General-Purpose Registers 
31 1615 87 0 16-bit 32-bit 

AH AL AX EAX 

BH BL BX EBX 

CH CL CX ECX 

DH DL DX EDX 
BP EBP 
Sl ESI 
DI EDI 
SP ESP 


Figure 3-5. Alternate General-Purpose Register Names 


3.4.1.1 General-Purpose Registers in 64-Bit Mode 


In 64-bit mode, there are 16 general purpose registers and the default operand size is 32 bits. However, general- 
purpose registers are able to work with either 32-bit or 64-bit operands. If a 32-bit operand size is specified: EAX, 
EBX, ECX, EDX, EDI, ESI, EBP, ESP, R8D - R15D are available. If a 64-bit operand size is specified: RAX, RBX, RCX, 
RDX, RDI, RSI, RBP, RSP, R8-R1i5 are available. R3D-R15D/R8-R15 represent eight new general-purpose registers. 
All of these registers can be accessed at the byte, word, dword, and qword level. REX prefixes are used to generate 
64-bit operand sizes or to reference registers R8-R15. 


Registers only available in 64-bit mode (R8-R15 and XMM8-XMM15) are preserved across transitions from 64-bit 
mode into compatibility mode then back into 64-bit mode. However, values of R8-R15 and XMM8-XMM15 are unde- 
fined after transitions from 64-bit mode through compatibility mode to legacy or real mode and then back through 
compatibility mode to 64-bit mode. 
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Table 3-2. Addressable General Purpose Registers 


Register Type Without REX With REX 

Byte Registers AL, BL, CL, DL, AH, BH, CH, DH AL, BL, CL, DL, DIL, SIL, BPL, SPL, R8B - R15B 

Word Registers AX, BX, CX, DX, DI, SI, BP, SP AX, BX, CX, DX, DI, SI, BP, SP, R8W - R15W 
Doubleword Registers EAX, EBX, ECX, EDX, EDI, ESI, EBP, ESP | EAX, EBX, ECX, EDX, EDI, ESI, EBP, ESP, R8D - R15D 
Quadword Registers N.A. RAX, RBX, RCX, RDX, RDI, RSI, RBP, RSP, R8 - R15 


In 64-bit mode, there are limitations on accessing byte registers. An instruction cannot reference legacy high- 
bytes (for example: AH, BH, CH, DH) and one of the new byte registers at the same time (for example: the low 
byte of the RAX register). However, instructions may reference legacy low-bytes (for example: AL, BL, CL or DL) 
and new byte registers at the same time (for example: the low byte of the R8 register, or RBP). The architecture 
enforces this limitation by changing high-byte references (AH, BH, CH, DH) to low byte references (BPL, SPL, DIL, 
SIL: the low 8 bits for RBP, RSP, RDI and RSI) for instructions using a REX prefix. 


When in 64-bit mode, operand size determines the number of valid bits in the destination general-purpose 
register: 


° 64-bit operands generate a 64-bit result in the destination general-purpose register. 


° 32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the destination general-purpose 
register. 


¢ 8-bit and 16-bit operands generate an 8-bit or 16-bit result. The upper 56 bits or 48 bits (respectively) of the 
destination general-purpose register are not modified by the operation. If the result of an 8-bit or 16-bit 
operation is intended for 64-bit address calculation, explicitly sign-extend the register to the full 64-bits. 


Because the upper 32 bits of 64-bit general-purpose registers are undefined in 32-bit modes, the upper 32 bits of 
any general-purpose register are not preserved when switching from 64-bit mode to a 32-bit mode (to protected 
mode or compatibility mode). Software must not depend on these bits to maintain a value after a 64-bit to 32-bit 
mode switch. 


3.4.2 Segment Registers 


The segment registers (CS, DS, SS, ES, FS, and GS) hold 16-bit segment selectors. A segment selector is a special 
pointer that identifies a segment in memory. To access a particular segment in memory, the segment selector for 
that segment must be present in the appropriate segment register. 


When writing application code, programmers generally create segment selectors with assembler directives and 
symbols. The assembler and other tools then create the actual segment selector values associated with these 
directives and symbols. If writing system code, programmers may need to create segment selectors directly. See 
Chapter 3, “Protected-Mode Memory Management,” in the Inte/® 64 and IA-32 Architectures Software Developer’s 
Manual, Volume 3A. 


How segment registers are used depends on the type of memory management model that the operating system or 
executive is using. When using the flat (unsegmented) memory model, segment registers are loaded with segment 
selectors that point to overlapping segments, each of which begins at address 0 of the linear address space (see 
Figure 3-6). These overlapping segments then comprise the linear address space for the program. Typically, two 
overlapping segments are defined: one for code and another for data and stacks. The CS segment register points 
to the code segment and all the other segment registers point to the data and stack segment. 


When using the segmented memory model, each segment register is ordinarily loaded with a different segment 
selector so that each segment register points to a different segment within the linear address space (see 

Figure 3-7). At any time, a program can thus access up to six segments in the linear address space. To access a 
segment not pointed to by one of the segment registers, a program must first load the segment selector for the 
segment to be accessed into a segment register. 
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Figure 3-6. Use of Segment Registers for Flat Memory Model 
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Figure 3-7. Use of Segment Registers in Segmented Memory Model 


Each of the segment registers is associated with one of three types of storage: code, data, or stack. For example, 
the CS register contains the segment selector for the code segment, where the instructions being executed are 
stored. The processor fetches instructions from the code segment, using a logical address that consists of the 
segment selector in the CS register and the contents of the EIP register. The EIP register contains the offset within 
the code segment of the next instruction to be executed. The CS register cannot be loaded explicitly by an applica- 
tion program. Instead, it is loaded implicitly by instructions or internal processor operations that change program 
control (such as procedure calls, interrupt handling, or task switching). 


The DS, ES, FS, and GS registers point to four data segments. The availability of four data segments permits effi- 
cient and secure access to different types of data structures. For example, four separate data segments might be 
created: one for the data structures of the current module, another for the data exported from a higher-level 
module, a third for a dynamically created data structure, and a fourth for data shared with another program. To 
access additional data segments, the application program must load segment selectors for these segments into the 
DS, ES, FS, and GS registers, as needed. 


The SS register contains the segment selector for the stack segment, where the procedure stack is stored for the 
program, task, or handler currently being executed. All stack operations use the SS register to find the stack 
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segment. Unlike the CS register, the SS register can be loaded explicitly, which permits application programs to set 
up multiple stacks and switch among them. 


See Section 3.3, “Memory Organization,” for an overview of how the segment registers are used in real-address 
mode. 


The four segment registers CS, DS, SS, and ES are the same as the segment registers found in the Intel 8086 and 
Intel 286 processors and the FS and GS registers were introduced into the IA-32 Architecture with the Intel386™ 
family of processors. 


3.4.2.1 Segment Registers in 64-Bit Mode 


In 64-bit mode: CS, DS, ES, SS are treated as if each segment base is 0, regardless of the value of the associated 
segment descriptor base. This creates a flat address space for code, data, and stack. FS and GS are exceptions. 
Both segment registers may be used as additional base registers in linear address calculations (in the addressing 
of local data and certain operating system data structures). 


Even though segmentation is generally disabled, segment register loads may cause the processor to perform 
segment access assists. During these activities, enabled processors will still perform most of the legacy checks on 
loaded values (even if the checks are not applicable in 64-bit mode). Such checks are needed because a segment 
register loaded in 64-bit mode may be used by an application running in compatibility mode. 


Limit checks for CS, DS, ES, SS, FS, and GS are disabled in 64-bit mode. 


3.4.3 EFLAGS Register 


The 32-bit EFLAGS register contains a group of status flags, a control flag, and a group of system flags. Figure 3-8 
defines the flags within this register. Following initialization of the processor (either by asserting the RESET pin or 
the INIT pin), the state of the EFLAGS register is OO000002H. Bits 1, 3, 5, 15, and 22 through 31 of this register 
are reserved. Software should not use or depend on the states of any of these bits. 


Some of the flags in the EFLAGS register can be modified directly, using special-purpose instructions (described in 
the following sections). There are no instructions that allow the whole register to be examined or modified directly. 


The following instructions can be used to move groups of flags to and from the procedure stack or the EAX register: 
LAHF, SAHF, PUSHF, PUSHFD, POPF, and POPFD. After the contents of the EFLAGS register have been transferred to 
the procedure stack or EAX register, the flags can be examined and modified using the processor’s bit manipulation 
instructions (BT, BTS, BTR, and BTC). 


When suspending a task (using the processor’s multitasking facilities), the processor automatically saves the state 
of the EFLAGS register in the task state segment (TSS) for the task being suspended. When binding itself to a new 
task, the processor loads the EFLAGS register with data from the new task’s TSS. 


When a call is made to an interrupt or exception handler procedure, the processor automatically saves the state of 
the EFLAGS registers on the procedure stack. When an interrupt or exception is handled with a task switch, the 
state of the EFLAGS register is saved in the TSS for the task being suspended. 
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Figure 3-8. EFLAGS Register 


As the IA-32 Architecture has evolved, flags have been added to the EFLAGS register, but the function and place- 
ment of existing flags have remained the same from one family of the IA-32 processors to the next. As a result, 
code that accesses or modifies these flags for one family of IA-32 processors works as expected when run on later 
families of processors. 


3.4.3.1 


Status Flags 


The status flags (bits 0, 2, 4, 6, 7, and 11) of the EFLAGS register indicate the results of arithmetic instructions, 
such as the ADD, SUB, MUL, and DIV instructions. The status flag functions are: 


CF (bit 0) 


PF (bit 2) 
AF (bit 4) 


ZF (bit 6) 
SF (bit 7) 


OF (bit 11) 


Carry flag — Set if an arithmetic operation generates a carry or a borrow out of the most- 
significant bit of the result; cleared otherwise. This flag indicates an overflow condition for 
unsigned-integer arithmetic. It is also used in multiple-precision arithmetic. 


Parity flag — Set if the least-significant byte of the result contains an even number of 1 bits; 
cleared otherwise. 

Auxiliary Carry flag — Set if an arithmetic operation generates a carry or a borrow out of bit 
3 of the result; cleared otherwise. This flag is used in binary-coded decimal (BCD) arithmetic. 
Zero flag — Set if the result is zero; cleared otherwise. 

Sign flag — Set equal to the most-significant bit of the result, which is the sign bit of a signed 
integer. (0 indicates a positive value and 1 indicates a negative value.) 

Overflow flag — Set if the integer result is too large a positive number or too small a negative 
number (excluding the sign-bit) to fit in the destination operand; cleared otherwise. This flag 
indicates an overflow condition for signed-integer (two’s complement) arithmetic. 


Of these status flags, only the CF flag can be modified directly, using the STC, CLC, and CMC instructions. Also the 
bit instructions (BT, BTS, BTR, and BTC) copy a specified bit into the CF flag. 
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The status flags allow a single arithmetic operation to produce results for three different data types: unsigned inte- 
gers, signed integers, and BCD integers. If the result of an arithmetic operation is treated as an unsigned integer, 
the CF flag indicates an out-of-range condition (carry or a borrow); if treated as a signed integer (two’s comple- 
ment number), the OF flag indicates a carry or borrow; and if treated as a BCD digit, the AF flag indicates a carry 
or borrow. The SF flag indicates the sign of a signed integer. The ZF flag indicates either a signed- or an unsigned- 
integer zero. 


When performing multiple-precision arithmetic on integers, the CF flag is used in conjunction with the add with 
carry (ADC) and subtract with borrow (SBB) instructions to propagate a carry or borrow from one computation to 
the next. 


The condition instructions Jcc (jump on condition code cc), SETcc (byte set on condition code cc), LOOPcc, and 
CMOVcc (conditional move) use one or more of the status flags as condition codes and test them for branch, set- 
byte, or end-loop conditions. 


3.4.3.2 DF Flag 


The direction flag (DF, located in bit 10 of the EFLAGS register) controls string instructions (MOVS, CMPS, SCAS, 
LODS, and STOS). Setting the DF flag causes the string instructions to auto-decrement (to process strings from 
high addresses to low addresses). Clearing the DF flag causes the string instructions to auto-increment 
(process strings from low addresses to high addresses). 


The STD and CLD instructions set and clear the DF flag, respectively. 


3.4.3.3 System Flags and IOPL Field 


The system flags and IOPL field in the EFLAGS register control operating-system or executive operations. They 
should not be modified by application programs. The functions of the system flags are as follows: 


TF (bit 8) Trap flag — Set to enable single-step mode for debugging; clear to disable single-step mode. 


IF (bit 9) Interrupt enable flag — Controls the response of the processor to maskable interrupt 
requests. Set to respond to maskable interrupts; cleared to inhibit maskable interrupts. 

IOPL (bits 12 and 13) 
I/O privilege level field — Indicates the I/O privilege level of the currently running program 
or task. The current privilege level (CPL) of the currently running program or task must be less 
than or equal to the I/O privilege level to access the I/O address space. The POPF and IRET 
instructions can modify this field only when operating at a CPL of 0. 

NT (bit 14) Nested task flag — Controls the chaining of interrupted and called tasks. Set when the 
current task is linked to the previously executed task; cleared when the current task is not 
linked to another task. 


RF (bit 16) Resume flag — Controls the processor’s response to debug exceptions. 

VM (bit 17) Virtual-8086 mode flag — Set to enable virtual-8086 mode; clear to return to protected 
mode without virtual-8086 mode semantics. 

AC (bit 18) Alignment check (or access control) flag — If the AM bit is set in the CRO register, align- 


ment checking of user-mode data accesses is enabled if and only if this flag is 1. 


If the SMAP bit is set in the CR4 register, explicit supervisor-mode data accesses to user-mode 
pages are allowed if and only if this bit is 1. See Section 4.6, “Access Rights,” in the Inte/® 64 
and IA-32 Architectures Software Developer’s Manual, Volume 3A. 


VIF (bit 19) Virtual interrupt flag — Virtual image of the IF flag. Used in conjunction with the VIP flag. 
(To use this flag and the VIP flag the virtual mode extensions are enabled by setting the VME 
flag in control register CR4.) 


VIP (bit 20) Virtual interrupt pending flag — Set to indicate that an interrupt is pending; clear when no 
interrupt is pending. (Software sets and clears this flag; the processor only reads it.) Used in 
conjunction with the VIF flag. 


ID (bit 21) Identification flag — The ability of a program to set or clear this flag indicates support for 
the CPUID instruction. 
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For a detailed description of these flags: see Chapter 3, “Protected-Mode Memory Management,” in the Inte/® 64 
and IA-32 Architectures Software Developer’s Manual, Volume 3A. 


3.4.3.4 RFLAGS Register in 64-Bit Mode 


In 64-bit mode, EFLAGS is extended to 64 bits and called RFLAGS. The upper 32 bits of RFLAGS register is 
reserved. The lower 32 bits of RFLAGS is the same as EFLAGS. 


3.5 INSTRUCTION POINTER 


The instruction pointer (EIP) register contains the offset in the current code segment for the next instruction to be 
executed. It is advanced from one instruction boundary to the next in straight-line code or it is moved ahead or 
backwards by a number of instructions when executing JMP, Jcc, CALL, RET, and IRET instructions. 


The EIP register cannot be accessed directly by software; it is controlled implicitly by control-transfer instructions 
(such as JMP, Jcc, CALL, and RET), interrupts, and exceptions. The only way to read the EIP register is to execute a 
CALL instruction and then read the value of the return instruction pointer from the procedure stack. The EIP 
register can be loaded indirectly by modifying the value of a return instruction pointer on the procedure stack and 
executing a return instruction (RET or IRET). See Section 6.2.4.2, “Return Instruction Pointer.” 


All IA-32 processors prefetch instructions. Because of instruction prefetching, an instruction address read from the 
bus during an instruction load does not match the value in the EIP register. Even though different processor gener- 
ations use different prefetching mechanisms, the function of the EIP register to direct program flow remains fully 
compatible with all software written to run on IA-32 processors. 


3.5.1 Instruction Pointer in 64-Bit Mode 


In 64-bit mode, the RIP register becomes the instruction pointer. This register holds the 64-bit offset of the next 
instruction to be executed. 64-bit mode also supports a technique called RIP-relative addressing. Using this tech- 
nique, the effective address is determined by adding a displacement to the RIP of the next instruction. 


3.6 OPERAND-SIZE AND ADDRESS-SIZE ATTRIBUTES 


When the processor is executing in protected mode, every code segment has a default operand-size attribute and 
address-size attribute. These attributes are selected with the D (default size) flag in the segment descriptor for the 
code segment (see Chapter 3, “Protected-Mode Memory Management,” in the Inte/® 64 and IA-32 Architectures 
Software Developer’s Manual, Volume 3A). When the D flag is set, the 32-bit operand-size and address-size attri- 
butes are selected; when the flag is clear, the 16-bit size attributes are selected. When the processor is executing 
in real-address mode, virtual-8086 mode, or SMM, the default operand-size and address-size attributes are always 
16 bits. 


The operand-size attribute selects the size of operands. When the 16-bit operand-size attribute is in force, oper- 
ands can generally be either 8 bits or 16 bits, and when the 32-bit operand-size attribute is in force, operands can 
generally be 8 bits or 32 bits. 


The address-size attribute selects the sizes of addresses used to address memory: 16 bits or 32 bits. When the 16- 
bit address-size attribute is in force, segment offsets and displacements are 16 bits. This restriction limits the size 
of a segment to 64 KBytes. When the 32-bit address-size attribute is in force, segment offsets and displacements 
are 32 bits, allowing up to 4 GBytes to be addressed. 


The default operand-size attribute and/or address-size attribute can be overridden for a particular instruction by 
adding an operand-size and/or address-size prefix to an instruction. See Chapter 2, “Instruction Format,” in the 
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A. The effect of this prefix applies only 
to the targeted instruction. 


Table 3-4 shows effective operand size and address size (when executing in protected mode or compatibility mode) 
depending on the settings of the D flag and the operand-size and address-size prefixes. 
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Table 3-3. Effective Operand- and Address-Size Attributes 


D Flag in Code Segment Descriptor 0 0 0 0 1 1 1 1 
Operand-Size Prefix 66H N N Y Y N N Y Y 
Address-Size Prefix 67H N Y N Y N ¥ N Y 

[EffectiveOperandSize = | 16 | 16 | 32e | 32 | 32 | 32 | 16 | 16 | 
Effective Address Size 16 32 16 32 32 16 32 16 
NOTES: 


Y: Yes - this instruction prefix is present. 
N: No - this instruction prefix is not present. 


3.6.1 Operand Size and Address Size in 64-Bit Mode 


In 64-bit mode, the default address size is 64 bits and the default operand size is 32 bits. Defaults can be over- 
ridden using prefixes. Address-size and operand-size prefixes allow mixing of 32/64-bit data and 32/64-bit 
addresses on an instruction-by-instruction basis. Table 3-4 shows valid combinations of the 66H instruction prefix 
and the REX.W prefix that may be used to specify operand-size overrides in 64-bit mode. Note that 16-bit 
addresses are not supported in 64-bit mode. 


REX prefixes consist of 4-bit fields that form 16 different values. The W-bit field in the REX prefixes is referred to as 
REX.W. If the REX.W field is properly set, the prefix specifies an operand size override to 64 bits. Note that software 
can still use the operand-size 66H prefix to toggle to a 16-bit operand size. However, setting REX.W takes prece- 
dence over the operand-size prefix (66H) when both are used. 


In the case of SSE/SSE2/SSE3/SSSE3 SIMD instructions: the 66H, F2H, and F3H prefixes are mandatory for 
opcode extensions. In such a case, there is no interaction between a valid REX.W prefix and a 66H opcode exten- 
sion prefix. 


See Chapter 2, “Instruction Format,” in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 2A. 


Table 3-4. Effective Operand- and Address-Size Attributes in 64-Bit Mode 


L Flag in Code Segment Descriptor 

1 1 1 1 1 1 1 1 
REX.W Prefix 0 0 0 0 1 1 1 1 
Operand-Size Prefix 66H N N Y Y N N Y Y 
Address-Size Prefix 67H N Y N Y N Y N Y 
Effective Operand Size 32 32 16 16 64 64 64 64 
Effective Address Size 64 32 64 32 64 32 64 32 
NOTES: 


Y: Yes - this instruction prefix is present. 
N: No - this instruction prefix is not present. 


3.7 OPERAND ADDRESSING 


IA-32 machine-instructions act on zero or more operands. Some operands are specified explicitly and others are 
implicit. The data for a source operand can be located in: 


¢ the instruction itself (an immediate operand) 
* a register 

* ~amemory location 

° an/J/O port 
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When an instruction returns data to a destination operand, it can be returned to: 
* aregister 

* amemory location 

° anI/O port 


3.7.1 Immediate Operands 


Some instructions use data encoded in the instruction itself as a source operand. These operands are called imme- 
diate operands (or simply immediates). For example, the following ADD instruction adds an immediate value of 14 
to the contents of the EAX register: 

ADD EAX, 14 


All arithmetic instructions (except the DIV and IDIV instructions) allow the source operand to be an immediate 
value. The maximum value allowed for an immediate operand varies among instructions, but can never be greater 
than the maximum value of an unsigned doubleword integer (227). 


3.7.2 Register Operands 

Source and destination operands can be any of the following registers, depending on the instruction being 
executed: 

¢ 32-bit general-purpose registers (EAX, EBX, ECX, EDX, ESI, EDI, ESP, or EBP) 

° 16-bit general-purpose registers (AX, BX, CX, DX, SI, DI, SP, or BP) 

° 8-bit general-purpose registers (AH, BH, CH, DH, AL, BL, CL, or DL) 

* segment registers (CS, DS, SS, ES, FS, and GS) 

° EFLAGS register 


° x87 FPU registers (STO through ST7, status word, control word, tag word, data operand pointer, and instruction 
pointer) 


¢ MMX registers (MMO through MM7) 

¢ XMM registers (XMMO through XMM7) and the MXCSR register 

* control registers (CRO, CR2, CR3, and CR4) and system table pointer registers (GDTR, LDTR, IDTR, and task 
register) 

¢ debug registers (DRO, DR1, DR2, DR3, DR6, and DR7) 

e MSR registers 


Some instructions (such as the DIV and MUL instructions) use quadword operands contained in a pair of 32-bit 
registers. Register pairs are represented with a colon separating them. For example, in the register pair EDX:EAX, 
EDX contains the high order bits and EAX contains the low order bits of a quadword operand. 


Several instructions (such as the PUSHFD and POPFD instructions) are provided to load and store the contents of 
the EFLAGS register or to set or clear individual flags in this register. Other instructions (such as the Jcc instruc- 
tions) use the state of the status flags in the EFLAGS register as condition codes for branching or other decision 
making operations. 


The processor contains a selection of system registers that are used to control memory management, interrupt and 
exception handling, task management, processor management, and debugging activities. Some of these system 
registers are accessible by an application program, the operating system, or the executive through a set of system 
instructions. When accessing a system register with a system instruction, the register is generally an implied 
operand of the instruction. 
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3.7.2.1 Register Operands in 64-Bit Mode 

Register operands in 64-bit mode can be any of the following: 

° 64-bit general-purpose registers (RAX, RBX, RCX, RDX, RSI, RDI, RSP, RBP, or R8-R15) 

¢ 32-bit general-purpose registers (EAX, EBX, ECX, EDX, ESI, EDI, ESP, EBP, or R8D-R15D) 
° 16-bit general-purpose registers (AX, BX, CX, DX, SI, DI, SP, BP, or R8W-R15W) 


° 8-bit general-purpose registers: AL, BL, CL, DL, SIL, DIL, SPL, BPL, and R8B-R1i5B are available using REX 
prefixes; AL, BL, CL, DL, AH, BH, CH, DH are available without using REX prefixes. 


¢ Segment registers (CS, DS, SS, ES, FS, and GS) 
¢ RFLAGS register 


° x87 FPU registers (STO through ST7, status word, control word, tag word, data operand pointer, and instruction 
pointer) 


¢ MMX registers (MMO through MM7) 
¢ XMM registers (XMMO through XMM15) and the MXCSR register 


* Control registers (CRO, CR2, CR3, CR4, and CR8) and system table pointer registers (GDTR, LDTR, IDTR, and 
task register) 


° Debug registers (DRO, DR1, DR2, DR3, DR6, and DR7) 
¢ MSR registers 
¢ RDX:RAX register pair representing a 128-bit operand 


3.7.3 Memory Operands 


Source and destination operands in memory are referenced by means of a segment selector and an offset (see 
Figure 3-9). Segment selectors specify the segment containing the operand. Offsets specify the linear or effective 
address of the operand. Offsets can be 32 bits (represented by the notation m16:32) or 16 bits (represented by the 
notation m16:16). 


15 0 31 fo) 


= ment Offset (or Linear Address) 
elector 


Figure 3-9. Memory Operand Address 


3.7.3.1 Memory Operands in 64-Bit Mode 


In 64-bit mode, a memory operand can be referenced by a segment selector and an offset. The offset can be 16 
bits, 32 bits or 64 bits (see Figure 3-10). 


15 O 63 0 


Segment Offset (or Linear Address) 
Selector 


Figure 3-10. Memory Operand Address in 64-Bit Mode 


3.7.4 Specifying a Segment Selector 


The segment selector can be specified either implicitly or explicitly. The most common method of specifying a 
segment selector is to load it in a segment register and then allow the processor to select the register implicitly, 
depending on the type of operation being performed. The processor automatically chooses a segment according to 
the rules given in Table 3-5. 
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When storing data in memory or loading data from memory, the DS segment default can be overridden to allow 
other segments to be accessed. Within an assembler, the segment override is generally handled with a colon “:” 
operator. For example, the following MOV instruction moves a value from register EAX into the segment pointed to 
by the ES register. The offset into the segment is contained in the EBX register: 


MOV ES:[EBX], EAX 


Table 3-5. Default Segment Selection Rules 


Reference Type | Register Used | Segment Used Default Selection Rule 
Instructions cs Code Segment All instruction fetches. 
Stack SS Stack Segment All stack pushes and pops. 
Any memory reference which uses the ESP or EBP register as a base 
register. 
Local Data DS Data Segment All data references, except when relative to stack or string destination. 
Destination Strings | ES Data Segment Destination of string instructions. 
pointed to with the 
ES register 


At the machine level, a segment override is specified with a segment-override prefix, which is a byte placed at the 
beginning of an instruction. The following default segment selections cannot be overridden: 


¢ Instruction fetches must be made from the code segment. 
* Destination strings in string instructions must be stored in the data segment pointed to by the ES register. 
¢ Push and pop operations must always reference the SS segment. 


Some instructions require a segment selector to be specified explicitly. In these cases, the 16-bit segment selector 
can be located in a memory location or in a 16-bit register. For example, the following MOV instruction moves a 
segment selector located in register BX into segment register DS: 

MOV DS, BX 


Segment selectors can also be specified explicitly as part of a 48-bit far pointer in memory. Here, the first double- 
word in memory contains the offset and the next word contains the segment selector. 


3.7.4.1 Segmentation in 64-Bit Mode 


In IA-32e mode, the effects of segmentation depend on whether the processor is running in compatibility mode or 
64-bit mode. In compatibility mode, segmentation functions just as it does in legacy IA-32 mode, using the 16-bit 
or 32-bit protected mode semantics described above. 


In 64-bit mode, segmentation is generally (but not completely) disabled, creating a flat 64-bit linear-address 
space. The processor treats the segment base of CS, DS, ES, SS as zero, creating a linear address that is equal to 
the effective address. The exceptions are the FS and GS segments, whose segment registers (which hold the 
segment base) can be used as additional base registers in some linear address calculations. 


3.7.5 Specifying an Offset 


The offset part of a memory address can be specified directly as a static value (called a displacement) or through 
an address computation made up of one or more of the following components: 


* Displacement — An 8-, 16-, or 32-bit value. 

¢ Base — The value in a general-purpose register. 

¢ Index — The value in a general-purpose register. 

*® Scale factor — A value of 2, 4, or 8 that is multiplied by the index value. 
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The offset which results from adding these components is called an effective address. Each of these components 
can have either a positive or negative (2s complement) value, with the exception of the scaling factor. Figure 3-11 
shows all the possible ways that these components can be combined to create an effective address in the selected 
segment. 


Base Index Scale — Displacement 
EAX Teas 
EBX oe Ft None 
EDX ; ECX ) | 2 | 8-bit 
esp | * | EDX | || + 
| esp | * | 4] 16-bit 

EBP les. | | 
eI \en / \8/ 32-bit 
EDI Ye 7 

Offset = Base + (Index * Scale) + Displacement 


Figure 3-11. Offset (or Effective Address) Computation 


The uses of general-purpose registers as base or index components are restricted in the following manner: 
¢ The ESP register cannot be used as an index register. 


¢ When the ESP or EBP register is used as the base, the SS segment is the default segment. In all other cases, 
the DS segment is the default segment. 


The base, index, and displacement components can be used in any combination, and any of these components can 
be NULL. A scale factor may be used only when an index also is used. Each possible combination is useful for data 
structures commonly used by programmers in high-level languages and assembly language. 


The following addressing modes suggest uses for common combinations of address components. 


* Displacement — A displacement alone represents a direct (uncomputed) offset to the operand. Because the 
displacement is encoded in the instruction, this form of an address is sometimes called an absolute or static 
address. It is commonly used to access a statically allocated scalar operand. 


¢ Base — A base alone represents an indirect offset to the operand. Since the value in the base register can 
change, it can be used for dynamic storage of variables and data structures. 


° Base + Displacement — A base register and a displacement can be used together for two distinct purposes: 


— Asan index into an array when the element size is not 2, 4, or 8 bytes—The displacement component 
encodes the static offset to the beginning of the array. The base register holds the results of a calculation 
to determine the offset to a specific element within the array. 


— Toaccess a field of a record: the base register holds the address of the beginning of the record, while the 
displacement is a static offset to the field. 


An important special case of this combination is access to parameters in a procedure activation record. A 
procedure activation record is the stack frame created when a procedure is entered. Here, the EBP register is 
the best choice for the base register, because it automatically selects the stack segment. This is a compact 
encoding for this common function. 


° (Index « Scale) + Displacement — This address mode offers an efficient way to index into a static array 
when the element size is 2, 4, or 8 bytes. The displacement locates the beginning of the array, the index 
register holds the subscript of the desired array element, and the processor automatically converts the 
subscript into an index by applying the scaling factor. 


¢ Base + Index + Displacement — Using two registers together supports either a two-dimensional array (the 
displacement holds the address of the beginning of the array) or one of several instances of an array of records 
(the displacement is an offset to a field within the record). 


° Base + (Index * Scale) + Displacement — Using all the addressing components together allows efficient 
indexing of a two-dimensional array when the elements of the array are 2, 4, or 8 bytes in size. 
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3.7.5.1 Specifying an Offset in 64-Bit Mode 


The offset part of a memory address in 64-bit mode can be specified directly as a static value or through an address 
computation made up of one or more of the following components: 


* Displacement — An 8-bit, 16-bit, or 32-bit value. 

¢ Base — The value in a 64-bit general-purpose register. 

* Index — The value in a 64-bit general-purpose register. 

° Scale factor — A value of 2, 4, or 8 that is multiplied by the index value. 


The base and index value can be specified in one of sixteen available general-purpose registers in most cases. See 
Chapter 2, “Instruction Format,” in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A. 


The following unique combination of address components is also available. 


° RIP + Displacement — In 64-bit mode, RIP-relative addressing uses a signed 32-bit displacement to 
calculate the effective address of the next instruction by sign-extend the 32-bit value and add to the 64-bit 
value in RIP. 


3.7.6 Assembler and Compiler Addressing Modes 


At the machine-code level, the selected combination of displacement, base register, index register, and scale factor 
is encoded in an instruction. All assemblers permit a programmer to use any of the allowable combinations of these 
addressing components to address operands. High-level language compilers will select an appropriate combination 
of these components based on the language construct a programmer defines. 


3.7.7 I/O Port Addressing 


The processor supports an I/O address space that contains up to 65,536 8-bit I/O ports. Ports that are 16-bit and 
32-bit may also be defined in the I/O address space. An I/O port can be addressed with either an immediate 
operand or a value in the DX register. See Chapter 19, “Input/Output,” for more information about I/O port 
addressing. 
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DATA TYPES 


This chapter introduces data types defined for the Intel 64 and IA-32 architectures. A section at the end of this 
chapter describes the real-number and floating-point concepts used in x87 FPU, SSE, SSE2, SSE3, SSSE3, SSE4 
and Intel AVX extensions. 


4.1 FUNDAMENTAL DATA TYPES 


The fundamental data types are bytes, words, doublewords, quadwords, and double quadwords (see Figure 4-1). 
A byte is eight bits, a word is 2 bytes (16 bits), a doubleword is 4 bytes (32 bits), a quadword is 8 bytes (64 bits), 
and a double quadword is 16 bytes (128 bits). A subset of the IA-32 architecture instructions operates on these 
fundamental data types without any additional operand typing. 


N 
15 87 0O 


High | Low 
Byte Byte | Word 


N+1 oN 
31 16 15 0 
High Word] Low Word | Doubleword 
N+2 N 

63 32 31 0 
High Doubleword Low Doubleword Quadword 
N+4 N 


127 64 63 
High Quadword Low Quadword 


N+8 N 


ie) 
Double 
Quadword 


Figure 4-1. Fundamental Data Types 


The quadword data type was introduced into the IA-32 architecture in the Intel486 processor; the double quadword 
data type was introduced in the Pentium Ill processor with the SSE extensions. 


Figure 4-2 shows the byte order of each of the fundamental data types when referenced as operands in memory. 
The low byte (bits 0 through 7) of each data type occupies the lowest address in memory and that address is also 
the address of the operand. 
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Figure 4-2. Bytes, Words, Doublewords, Quadwords, and Double Quadwords in Memory 


4.1.1 Alignment of Words, Doublewords, Quadwords, and Double Quadwords 


Words, doublewords, and quadwords do not need to be aligned in memory on natural boundaries. The natural 
boundaries for words, double words, and quadwords are even-numbered addresses, addresses evenly divisible by 
four, and addresses evenly divisible by eight, respectively. However, to improve the performance of programs, data 
structures (especially stacks) should be aligned on natural boundaries whenever possible. The reason for this is 
that the processor requires two memory accesses to make an unaligned memory access; aligned accesses require 
only one memory access. A word or doubleword operand that crosses a 4-byte boundary or a quadword operand 
that crosses an 8-byte boundary is considered unaligned and requires two separate memory bus cycles for access. 


Some instructions that operate on double quadwords require memory operands to be aligned on a natural 
boundary. These instructions generate a general-protection exception (#GP) if an unaligned operand is specified. A 
natural boundary for a double quadword is any address evenly divisible by 16. Other instructions that operate on 
double quadwords permit unaligned access (without generating a general-protection exception). However, addi- 
tional memory bus cycles are required to access unaligned data from memory. 


4.2 NUMERIC DATA TYPES 


Although bytes, words, and doublewords are fundamental data types, some instructions support additional inter- 
pretations of these data types to allow operations to be performed on numeric data types (signed and unsigned 
integers, and floating-point numbers). Single-precision (32-bit) floating-point and double-precision (64-bit) 
floating-point data types are supported across all generations of SSE extensions and Intel AVX extensions. Half- 
precision (16-bit) floating-point data type is supported only with F16C extensions (VCVTPH2PS, VCVTPS2PH). See 
Figure 4-3. 
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Figure 4-3. Numeric Data Types 


4.2.1 Integers 


The Intel 64 and IA-32 architectures define two types of integers: unsigned and signed. Unsigned integers are ordi- 
nary binary values ranging from 0 to the maximum positive number that can be encoded in the selected operand 
size. Signed integers are two’s complement binary values that can be used to represent both positive and negative 
integer values. 


Some integer instructions (such as the ADD, SUB, PADDB, and PSUBB instructions) operate on either unsigned or 
signed integer operands. Other integer instructions (such as IMUL, MUL, IDIV, DIV, FIADD, and FISUB) operate on 
only one integer type. 


The following sections describe the encodings and ranges of the two types of integers. 


4.2.1.1 Unsigned Integers 


Unsigned integers are unsigned binary numbers contained in a byte, word, doubleword, and quadword. Their 
values range from 0 to 255 for an unsigned byte integer, from 0 to 65,535 for an unsigned word integer, from 0 
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to 232 - 1 for an unsigned doubleword integer, and from 0 to 2° - 1 for an unsigned quadword integer. Unsigned 
integers are sometimes referred to as ordinals. 


4.2.1.2 Signed Integers 


Signed integers are signed binary numbers held in a byte, word, doubleword, or quadword. All operations on signed 
integers assume a two's complement representation. The sign bit is located in bit 7 in a byte integer, bit 15 ina 
word integer, bit 31 in a doubleword integer, and bit 63 in a quadword integer (see the signed integer encodings in 
Table 4-1). 


Table 4-1. Signed Integer Encodings 


Class Two's Complement Encoding 
Sign 
Positive Largest 0 11.11 
Smallest 0 00..01 
Zero 0 00..00 
Negative Smallest 1 11.11 
Largest 1 00..00 
Integer indefinite 1 00..00 
Signed Byte Integer: <7 bits > 
Signed Word Integer: < 15 bits > 
Signed Doubleword Integer: < 31 bits > 
Signed Quadword Integer: < 63 bits > 


The sign bit is set for negative integers and cleared for positive integers and zero. Integer values range from -128 
to +127 for a byte integer, from -32,768 to +32,767 for a word integer, from -23! to +23! - 1 for a doubleword 
integer, and from —2©3 to +263 - 1 for a quadword integer. 


When storing integer values in memory, word integers are stored in 2 consecutive bytes; doubleword integers are 
stored in 4 consecutive bytes; and quadword integers are stored in 8 consecutive bytes. 


The integer indefinite is a special value that is sometimes returned by the x87 FPU when operating on integer 
values. For more information, see Section 8.2.1, “Indefinites.” 


4.2.2 Floating-Point Data Types 


The IA-32 architecture defines and operates on three floating-point data types: single-precision floating-point, 
double-precision floating-point, and double-extended precision floating-point (see Figure 4-3). The data formats 
for these data types correspond directly to formats specified in the IEEE Standard 754 for Binary Floating-Point 
Arithmetic. 


Half-precision (16-bit) floating-point data type is supported only for conversion operation with single-precision 
floating data using F16C extensions (VCVTPH2PS, VCVTPS2PH). 


Table 4-2 gives the length, precision, and approximate normalized range that can be represented by each of these 
data types. Denormal values are also supported in each of these types. 
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Table 4-2. Length, Precision, and Range of Floating-Point Data Types 


Data Type Length Precision Approximate Normalized Range 
(Bits) Binary Decimal 
Half Precision 16 11 24 tp 2 3.1 x 10° to 6.50 x 107 
Single Precision 32 24 27126 to 2127 1.18 x 10°38 to 3.40 x 1038 
Double Precision 64 53 2-022 to 21023 2.23 x 10°38 to 1.79 x 10308 
Double Extended 80 64 2716382 tq 216383 3.37 x 10-4932 to 1.18 x 104932 
Precision 


NOTE 


Section 4.8, “Real Numbers and Floating-Point Formats,” gives an overview of the IEEE Standard 
754 floating-point formats and defines the terms integer bit, QNaN, SNaN, and denormal value. 


Table 4-3 shows the floating-point encodings for zeros, denormalized finite numbers, normalized finite numbers, 
infinites, and NaNs for each of the three floating-point data types. It also gives the format for the QNaN floating- 
point indefinite value. (See Section 4.8.3.7, “QNaN Floating-Point Indefinite,” for a discussion of the use of the 


QNaN floating-point indefinite value. ) 


For the single-precision and double-precision formats, only the fraction part of the significand is encoded. The 
integer is assumed to be 1 for all numbers except 0 and denormalized finite numbers. For the double extended- 
precision format, the integer is contained in bit 63, and the most-significant fraction bit is bit 62. Here, the integer 
is explicitly set to 1 for normalized numbers, infinities, and NaNs, and to O for zero and denormalized numbers. 


Table 4-3. Floating-Point Number and NaN Encodings 


. . Significand 
Class Sign Biased Exponent : 
Integer! Fraction 
Positive +00 0 11.11 1 00..00 
+Normals 0 11..10 1 11.11 
0 00.01 1 00.00 
+Denormals 0 00..00 0 11.11 
0 00..00 0 00..01 
+Zero 0 00..00 0 00..00 
Negative —Zero 1 00..00 0 00..00 
—Denormals 1 00..00 0 00..01 
1 00..00 0 11.11 
—Normals 1 00..01 1 00..00 
1 11.10 1 11.11 
-00 1 11.11 1 00..00 
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Table 4-3. Floating-Point Number and NaN Encodings (Contd.) 


: . Significand 
Class Sign Biased Exponent 7 - 
Integer Fraction 
NaNs SNaN X 11..11 1 OX..XX2 
QNaN X 11.11 1 1X..XX 
QNaN Floating- 1 11.11 1 10..00 
Point Indefinite 
Half-Precision < 5Bits > < 10 Bits > 
Single-Precision: <— 8 Bits > <— 23 Bits > 
Double-Precision: — 11 Bits > — 52 Bits > 
Double Extended-Precision: <— 15 Bits > <— 63 Bits > 


NOTES: 
1. Integer bit is implied and not stored for single-precision and double-precision formats. 
2. The fraction for SNaN encodings must be non-zero with the most-significant bit 0. 


The exponent of each floating-point data type is encoded in biased format; see Section 4.8.2.2, “Biased Exponent.” 
The biasing constant is 15 for the half-precision format, 127 for the single-precision format, 1023 for the double- 
precision format, and 16,383 for the double extended-precision format. 


When storing floating-point values in memory, half-precision values are stored in 2 consecutive bytes in memory; 
single-precision values are stored in 4 consecutive bytes in memory; double-precision values are stored in 8 
consecutive bytes; and double extended-precision values are stored in 10 consecutive bytes. 


The single-precision and double-precision floating-point data types are operated on by x87 FPU, and 
SSE/SSE2/SSE3/SSE4.1 and Intel AVX instructions. The double-extended-precision floating-point format is only 
operated on by the x87 FPU. See Section 11.6.8, “Compatibility of SIMD and x87 FPU Floating-Point Data Types,” 
for a discussion of the compatibility of single-precision and double-precision floating-point data types between the 
x87 FPU and SSE/SSE2/SSE3 extensions. 


4.3 POINTER DATA TYPES 


Pointers are addresses of locations in memory. 


In non-64-bit modes, the architecture defines two types of pointers: a near pointer and a far pointer. A near 
pointer is a 32-bit (or 16-bit) offset (also called an effective address) within a segment. Near pointers are used 
for all memory references in a flat memory model or for references in a segmented model where the identity of the 
segment being accessed is implied. 


A far pointer is a logical address, consisting of a 16-bit segment selector and a 32-bit (or 16-bit) offset. Far pointers 
are used for memory references in a segmented memory model where the identity of a segment being accessed 
must be specified explicitly. Near and far pointers with 32-bit offsets are shown in Figure 4-4. 


Near Pointer 


31 0 


Far Pointer or Logical Address 


Segment Selector 


47 32 31 0 


Figure 4-4. Pointer Data Types 


4-6 Vol. 1 


DATA TYPES 


4.3.1 Pointer Data Types in 64-Bit Mode 


In 64-bit mode (a sub-mode of IA-32e mode), a near pointer is 64 bits. This equates to an effective address. Far 
pointers in 64-bit mode can be one of three forms: 


¢ 16-bit segment selector, 16-bit offset if the operand size is 32 bits 
16-bit segment selector, 32-bit offset if the operand size is 32 bits 
16-bit segment selector, 64-bit offset if the operand size is 64 bits 
See Figure 4-5. 
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Figure 4-5. Pointers in 64-Bit Mode 


4.4 BIT FIELD DATA TYPE 


A bit field (see Figure 4-6) is a contiguous sequence of bits. It can begin at any bit position of any byte in memory 
and can contain up to 32 bits. 
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Figure 4-6. Bit Field Data Type 
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4.5 STRING DATA TYPES 


Strings are continuous sequences of bits, bytes, words, or doublewords. A bit string can begin at any bit position 
of any byte and can contain up to 234 - 1 bits. A byte string can contain bytes, words, or doublewords and can 
range from zero to 232- 1 bytes (4 GBytes). 


4.6 PACKED SIMD DATA TYPES 


Intel 64 and IA-32 architectures define and operate on a set of 64-bit and 128-bit packed data type for use in SIMD 
operations. These data types consist of fundamental data types (packed bytes, words, doublewords, and quad- 
words) and numeric interpretations of fundamental types for use in packed integer and packed floating-point oper- 
ations. 


4.6.1 64-Bit SIMD Packed Data Types 


The 64-bit packed SIMD data types were introduced into the IA-32 architecture in the Intel MMX technology. They 
are operated on in MMX registers. The fundamental 64-bit packed data types are packed bytes, packed words, and 
packed doublewords (see Figure 4-7). When performing numeric SIMD operations on these data types, these data 
types are interpreted as containing byte, word, or doubleword integer values. 
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Figure 4-7. 64-Bit Packed SIMD Data Types 


4.6.2 128-Bit Packed SIMD Data Types 


The 128-bit packed SIMD data types were introduced into the IA-32 architecture in the SSE extensions and used 
with SSE2, SSE3 and SSSE3 extensions. They are operated on primarily in the 128-bit XMM registers and memory. 
The fundamental 128-bit packed data types are packed bytes, packed words, packed doublewords, and packed 
quadwords (see Figure 4-8). When performing SIMD operations on these fundamental data types in XMM registers, 
these data types are interpreted as containing packed or scalar single-precision floating-point or double-precision 
floating-point values, or as containing packed byte, word, doubleword, or quadword integer values. 
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Figure 4-8. 128-Bit Packed SIMD Data Types 
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Binary-coded decimal integers (BCD integers) are unsigned 4-bit integers with valid values ranging from 0 to 9. IA- 
32 architecture defines operations on BCD integers located in one or more general-purpose registers or in one or 


more x87 FPU registers (see Figure 4-9). 
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Figure 4-9. BCD Data Types 


When operating on BCD integers in general-purpose registers, the BCD values can be unpacked (one BCD digit per 
byte) or packed (two BCD digits per byte). The value of an unpacked BCD integer is the binary value of the low half- 
byte (bits 0 through 3). The high half-byte (bits 4 through 7) can be any value during addition and subtraction, but 
must be zero during multiplication and division. Packed BCD integers allow two BCD digits to be contained in one 
byte. Here, the digit in the high half-byte is more significant than the digit in the low half-byte. 


When operating on BCD integers in x87 FPU data registers, BCD values are packed in an 80-bit format and referred 
to as decimal integers. In this format, the first 9 bytes hold 18 BCD digits, 2 digits per byte. The least-significant 
digit is contained in the lower half-byte of byte 0 and the most-significant digit is contained in the upper half-byte 
of byte 9. The most significant bit of byte 10 contains the sign bit (0 = positive and 1 = negative; bits 0 through 6 
of byte 10 are don’t care bits). Negative decimal integers are not stored in two's complement form; they are distin- 
guished from positive decimal integers only by the sign bit. The range of decimal integers that can be encoded in 
this format is -10!8+1 to 108 -1. 


The decimal integer format exists in memory only. When a decimal integer is loaded in an x87 FPU data register, it 
is automatically converted to the double-extended-precision floating-point format. All decimal integers are exactly 
representable in double extended-precision format. 


Table 4-4 gives the possible encodings of value in the decimal integer data type. 


Table 4-4. Packed Decimal Integer Encodings 


: Magnitude 
Class Sign oe = a oe ae 
digit digit digit digit we digit 
Positive 
Largest 0 0000000 1001 1001 1001 1001 = 1001 
Smallest 0 0000000 0000 0000 0000 0000 7 0001 
Zero 0 0000000 0000 0000 0000 0000 x 0000 
Negative 
Zero 1 0000000 0000 0000 0000 0000 “ 0000 
Smallest 1 0000000 0000 0000 0000 0000 e 0001 
Largest 1 0000000 1001 1001 1001 1001 = 1001 
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Table 4-4. Packed Decimal Integer Encodings (Contd.) 


; Magnitude 
Class Sign — — 
digit digit digit digit sit digit 
Packed BCD 1 1111111 1111 1111 1100 0000 o 0000 
Integer 
Indefinite 
< 1 byte > < 9 bytes > 


The packed BCD integer indefinite encoding (FFFFCOOOO00000000000H) is stored by the FBSTP instruction in 
response to a masked floating-point invalid-operation exception. Attempting to load this value with the FBLD 
instruction produces an undefined result. 


4.8 REAL NUMBERS AND FLOATING-POINT FORMATS 


This section describes how real numbers are represented in floating-point format in x87 FPU and 
SSE/SSE2/SSE3/SSE4.1 and Intel AVX floating-point instructions. It also introduces terms such as normalized 
numbers, denormalized numbers, biased exponents, signed zeros, and NaNs. Readers who are already familiar 
with floating-point processing techniques and the IEEE Standard 754 for Binary Floating-Point Arithmetic may wish 
to skip this section. 


4.8.1 Real Number System 


As shown in Figure 4-10, the real-number system comprises the continuum of real numbers from minus infinity (— 
co) to plus infinity (+ ©). 


Because the size and number of registers that any computer can have is limited, only a subset of the real-number 
continuum can be used in real-number (floating-point) calculations. As shown at the bottom of Figure 4-10, the 
subset of real numbers that the IA-32 architecture supports represents an approximation of the real number 
system. The range and precision of this real-number subset is determined by the IEEE Standard 754 floating-point 
formats. 


4.8.2 Floating-Point Format 


To increase the speed and efficiency of real-number computations, computers and microprocessors typically repre- 
sent real numbers in a binary floating-point format. In this format, a real number has three parts: a sign, a signif- 
icand, and an exponent (see Figure 4-11). 


The sign is a binary value that indicates whether the number is positive (0) or negative (1). The significand has 
two parts: a 1-bit binary integer (also referred to as the J-bit) and a binary fraction. The integer-bit is often not 
represented, but instead is an implied value. The exponent is a binary integer that represents the base-2 power by 
which the significand is multiplied. 


Table 4-5 shows how the real number 178.125 (in ordinary decimal format) is stored in IEEE Standard 754 floating- 
point format. The table lists a progression of real number notations that leads to the single-precision, 32-bit 
floating-point format. In this format, the significand is normalized (see Section 4.8.2.1, “Normalized Numbers”) 
and the exponent is biased (see Section 4.8.2.2, “Biased Exponent”). For the single-precision floating-point 
format, the biasing constant is +127. 
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Binary Real Number System 
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Figure 4-10. Binary Real Number System 


Sign 


Exponent Significand 


Fraction 


Integer or J-Bit - 


Figure 4-11. Binary Floating-Point Format 


Table 4-5. Real and Floating-Point Number Notation 


Notation Value 
Ordinary Decimal 178.125 
Scientific Decimal 1.78125E192 
Scientific Binary 1.0110010001E3111 
Scientific Binary 1.0110010001€310000110 
(Biased Exponent) 
IEEE Single-Precision Format Sign Biased Exponent Normalized Significand 
0 10000110 0110010001 0000000000000 
1. (Implied) 
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4.8.2.1 Normalized Numbers 


In most cases, floating-point numbers are encoded in normalized form. This means that except for zero, the signif- 
icand is always made up of an integer of 1 and the following fraction: 


1. fff... ff 


For values less than 1, leading zeros are eliminated. (For each leading zero eliminated, the exponent is decre- 
mented by one.) 


Representing numbers in normalized form maximizes the number of significant digits that can be accommodated 
in a significand of a given width. To summarize, a normalized real number consists of a normalized significand that 
represents a real number between 1 and 2 and an exponent that specifies the number's binary point. 


4.8.2.2 Biased Exponent 


In the IA-32 architecture, the exponents of floating-point numbers are encoded in a biased form. This means that 
a constant is added to the actual exponent so that the biased exponent is always a positive number. The value of 
the biasing constant depends on the number of bits available for representing exponents in the floating-point 
format being used. The biasing constant is chosen so that the smallest normalized number can be reciprocated 
without overflow. 


See Section 4.2.2, “Floating-Point Data Types,” for a list of the biasing constants that the IA-32 architecture uses 
for the various sizes of floating-point data-types. 


4.8.3 Real Number and Non-number Encodings 


A variety of real numbers and special values can be encoded in the IEEE Standard 754 floating-point format. These 
numbers and values are generally divided into the following classes: 


¢ Signed zeros 

¢ Denormalized finite numbers 

¢ Normalized finite numbers 

° Signed infinities 

° NaNs 

¢ Indefinite numbers 

(The term NaN stands for “Not a Number.”) 


Figure 4-12 shows how the encodings for these numbers and non-numbers fit into the real number continuum. The 
encodings shown here are for the IEEE single-precision floating-point format. The term “S” indicates the sign bit, 
“E” the biased exponent, and “Sig” the significand. The exponent values are given in decimal. The integer bit is 
shown for the significands, even though the integer bit is implied in single-precision floating-point format. 
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NaN NaN 
— Denormalized Finite + Denormalized Finite 
—co — Normalized Finite NX -0+0 + Normalized Finite + co 
t t t—+—+ t t 
Real Number and NaN Encodings For 32-Bit Floating-Point Format 

S_E Sig! S_E Sig! 

1 0 0.000... -0 +0/0 0 0.000... 

1 0 O.XXX...2  Enonneeen snenonne 0 0 0.XXX...2 
A tn254 | OKs | aaleee eNetmalized' 9 tc2s4| i Xes 
1} 255 1.000... — oo +co |0} 255 | 1.000... 
x3] 255 | 1.0Xx...2 | SNaN SNaN [x4 255 | 1.0XX...2 
Xx} 255 | 1.1XX.... |] QNaN QNaN [X93 255 | 1.1XX... 
NOTES: 


1. Integer bit of fraction implied for 
single-precision floating-point format. 


2. Fraction must be non-zero. 
3. Sign bit ignored. 


Figure 4-12. Real Numbers and NaNs 


An IA-32 processor can operate on and/or return any of these values, depending on the type of computation being 
performed. The following sections describe these number and non-number classes. 


4.8.3.1 Signed Zeros 


Zero can be represented as a +0 or a —0 depending on the sign bit. Both encodings are equal in value. The sign of 
a zero result depends on the operation being performed and the rounding mode being used. Signed zeros have 
been provided to aid in implementing interval arithmetic. The sign of a zero may indicate the direction from which 
underflow occurred, or it may indicate the sign of an «that has been reciprocated. 


4.8.3.2 Normalized and Denormalized Finite Numbers 


Non-zero, finite numbers are divided into two classes: normalized and denormalized. The normalized finite 
numbers comprise all the non-zero finite values that can be encoded in a normalized real number format between 
zero and -~. In the single-precision floating-point format shown in Figure 4-12, this group of numbers includes all 
the numbers with biased exponents ranging from 1 to 25449 (unbiased, the exponent range is from —12649 to 
+12719). 


When floating-point numbers become very close to zero, the normalized-number format can no longer be used to 
represent the numbers. This is because the range of the exponent is not large enough to compensate for shifting 
the binary point to the right to eliminate leading zeros. 


When the biased exponent is zero, smaller numbers can only be represented by making the integer bit (and 
perhaps other leading bits) of the significand zero. The numbers in this range are called denormalized numbers. 
The use of leading zeros with denormalized numbers allows smaller numbers to be represented. However, this 
denormalization may cause a loss of precision (the number of significant bits is reduced by the leading zeros). 


When performing normalized floating-point computations, an IA-32 processor normally operates on normalized 
numbers and produces normalized numbers as results. Denormalized numbers represent an underflow condition. 
The exact conditions are specified in Section 4.9.1.5, “Numeric Underflow Exception (#U).” 


A denormalized number is computed through a technique called gradual underflow. Table 4-6 gives an example of 
gradual underflow in the denormalization process. Here the single-precision format is being used, so the minimum 
exponent (unbiased) is -126;9. The true result in this example requires an exponent of —129,9 in order to have a 
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normalized number. Since -129,, is beyond the allowable exponent range, the result is denormalized by inserting 
leading zeros until the minimum exponent of —126 49 is reached. 


Table 4-6. Denormalization Process 


Operation Sign Exponent* Significand 

True Result 0 -129 1.01011100000...00 
Denormalize 0 -128 0.10101110000...00 
Denormalize 0 -127 0.01010111000...00 
Denormalize 0 -126 0.00101011100...00 
Denormal Result 0 -126 0.00101011100...00 


* Expressed as an unbiased, decimal number. 


In the extreme case, all the significant bits are shifted out to the right by leading zeros, creating a zero result. 
The Intel 64 and IA-32 architectures deal with denormal values in the following ways: 
¢ It avoids creating denormals by normalizing numbers whenever possible. 


¢ It provides the floating-point underflow exception to permit programmers to detect cases when denormals are 
created. 


e It provides the floating-point denormal-operand exception to permit procedures or programs to detect when 
denormals are being used as source operands for computations. 


4.8.3.3 Signed Infinities 


The two infinities, + 0 and —, represent the maximum positive and negative real numbers, respectively, that can 
be represented in the floating-point format. Infinity is always represented by a significand of 1.00...00 (the integer 
bit may be implied) and the maximum biased exponent allowed in the specified format (for example, 25549 for the 
single-precision format). 


The signs of infinities are observed, and comparisons are possible. Infinities are always interpreted in the affine 
sense; that is, -- is less than any finite number and + is greater than any finite number. Arithmetic on infinities 
is always exact. Exceptions are generated only when the use of an infinity as a source operand constitutes an 
invalid operation. 


Whereas denormalized numbers may represent an underflow condition, the two « numbers may represent the 
result of an overflow condition. Here, the normalized result of a computation has a biased exponent greater than 
the largest allowable exponent for the selected result format. 


4.8.3.4 | NaNs 


Since NaNs are non-numbers, they are not part of the real number line. In Figure 4-12, the encoding space for 
NaNs in the floating-point formats is shown above the ends of the real number line. This space includes any value 
with the maximum allowable biased exponent and a non-zero fraction (the sign bit is ignored for NaNs). 


The IA-32 architecture defines two classes of NaNs: quiet NaNs (QNaNs) and signaling NaNs (SNaNs). A QNaN is a 
NaN with the most significant fraction bit set; an SNaN is a NaN with the most significant fraction bit clear. QNaNs 
are allowed to propagate through most arithmetic operations without signaling an exception. SNaNs generally 
signal a floating-point invalid-operation exception whenever they appear as operands in arithmetic operations. 


SNaNs are typically used to trap or invoke an exception handler. They must be inserted by software; that is, the 
processor never generates an SNaN as a result of a floating-point operation. 
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4.8.3.5 Operating on SNaNs and QNaNs 


When a floating-point operation is performed on an SNaN and/or a QNaN, the result of the operation is either a 
QNaN delivered to the destination operand or the generation of a floating-point invalid operation exception, 
depending on the following rules: 


If one of the source operands is an SNaN and the floating-point invalid-operation exception is not masked (see 
Section 4.9.1.1, “Invalid Operation Exception (#I)”), then a floating-point invalid-operation exception is 
signaled and no result is stored in the destination operand. If one of the source operands is a QNaN and the 
floating-point invalid-operation exception is not masked and the operation is one that generates an invalid- 
operation exception for QNaN operands as described in Section 8.5.1.2, “Invalid Arithmetic Operand Exception 
(#IA),” or Section 11.5.2.1, “Invalid Operation Exception (#I)”, then a floating-point invalid-operation 
exception is signaled and no result is stored in the destination operand. 


If either or both of the source operands are NaNs and floating-point invalid-operation exception is masked, the 
result is as shown in Table 4-7. When an SNaN is converted to a QNaN, the conversion is handled by setting the 
most-significant fraction bit of the SNaN to 1. Also, when one of the source operands is an SNaN, or when it is 
a QNaN and the operation is one that generates an invalid-operation exception for QNaN operands as described 
in Section 8.5.1.2, “Invalid Arithmetic Operand Exception (#IA),” or Section 11.5.2.1, “Invalid Operation 
Exception (#1)”, then the floating-point invalid-operation exception flag is set. Note that for some combinations 
of source operands, the result is different for x87 FPU operations and for SSE/SSE2/SSE3/SSE4.1 operations. 
Intel AVX follows the same behavior as SSE/SSE2/SSE3/SSE4.1 in this respect. 


When neither of the source operands is a NaN, but the operation generates a floating-point invalid-operation 
exception (see Tables 8-10 and 11-1), the result is commonly a QNaN FP Indefinite (Section 4.8.3.7). 


Any exceptions to the behavior described in Table 4-7 are described in Section 8.5.1.2, “Invalid Arithmetic Operand 
Exception (#IA),” and Section 11.5.2.1, “Invalid Operation Exception (#1).” 


Table 4-7. Rules for Handling NaNs 


Source Operands Result! 


SNaN and QNaN x87 FPU — QNaN source operand. 


SSE/SSE2/SSE3/SSE4.1/AVX — First source operand (if this operand is an 
SNaN, it is converted to a QNaN) 


Two SNaNs x87 FPU—SNaN source operand with the larger significand, converted into a 
QNaN 
SSE/SSE2/SSE3/SSE4.1/AVX — First source operand converted to a QNaN 
Two QNaNs x87 FPU — QNaN source operand with the larger 
significand 
SSE/SSE2/SSE3/SSE4.1/AVX — First source operand 
SNaN and a floating-point value SNaN source operand, converted into a QNaN 
QNaN and a floating-point value QNaN source operand 


SNaN (for instructions that take only one operand) | SNaN source operand, converted into a QNaN 


QNaN (for instructions that take only one operand) | QNaN source operand 


NOTE: 

1. For SSE/SSE2/SSE3/SSE4.1 instructions, the first operand is generally a source operand that becomes the destination operand. For 
AVX instructions, the first source operand is usually the 2nd operand in a non-destructive source syntax. Within the Result column, 
the x87 FPU notation also applies to the FISTTP instruction in SSE3; the SSE3 notation applies to the SIMD floating-point instruc- 
tions. 


4.8.3.6 Using SNaNs and QNaNs in Applications 


Except for the rules given at the beginning of Section 4.8.3.4, “NaNs,” for encoding SNaNs and QNaNs, software is 
free to use the bits in the significand of a NaN for any purpose. Both SNaNs and QNaNs can be encoded to carry and 


store data, such as diagnostic information. 
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By unmasking the invalid operation exception, the programmer can use signaling NaNs to trap to the exception 
handler. The generality of this approach and the large number of NaN values that are available provide the sophis- 
ticated programmer with a tool that can be applied to a variety of special situations. 


For example, a compiler can use signaling NaNs as references to uninitialized (real) array elements. The compiler 
can preinitialize each array element with a signaling NaN whose significand contains the index (relative position) of 
the element. Then, if an application program attempts to access an element that it has not initialized, it can use the 
NaN placed there by the compiler. If the invalid operation exception is unmasked, an interrupt will occur, and the 
exception handler will be invoked. The exception handler can determine which element has been accessed, since 
the operand address field of the exception pointer will point to the NaN, and the NaN will contain the index number 
of the array element. 


Quiet NaNs are often used to speed up debugging. In its early testing phase, a program often contains multiple 
errors. An exception handler can be written to save diagnostic information in memory whenever it is invoked. After 
storing the diagnostic data, it can supply a quiet NaN as the result of the erroneous instruction, and that NaN can 
point to its associated diagnostic area in memory. The program will then continue, creating a different NaN for each 
error. When the program ends, the NaN results can be used to access the diagnostic data saved at the time the 
errors occurred. Many errors can thus be diagnosed and corrected in one test run. 


In embedded applications that use computed results in further computations, an undetected QNaN can invalidate 
all subsequent results. Such applications should therefore periodically check for QNaNs and provide a recovery 
mechanism to be used if a QNaN result is detected. 


4.8.3.7 QNaN Floating-Point Indefinite 


For the floating-point data type encodings (single-precision, double-precision, and double-extended-precision), 
one unique encoding (a QNaN) is reserved for representing the special value QNaN floating-point indefinite. The 
x87 FPU and the SSE/SSE2/SSE3/SSE4.1/AVX extensions return these indefinite values as responses to some 
masked floating-point exceptions. Table 4-3 shows the encoding used for the QNaN floating-point indefinite. 


4.8.3.8 Half-Precision Floating-Point Operation 


Half-precision floating-point values are not used by the processor directly for arithmetic operations. Two instruc- 
tions, VCVTPH2PS, VCVTPS2PH, provide conversion only between half-precision and single-precision floating-point 
values. 


The SIMD floating-point exception behavior of VCVTPH2PS and VCVTPS2PH are described in Section 14.4.1. 


4.8.4 Rounding 


When performing floating-point operations, the processor produces an infinitely precise floating-point result in the 
destination format (single-precision, double-precision, or double extended-precision floating-point) whenever 
possible. However, because only a subset of the numbers in the real number continuum can be represented in IEEE 
Standard 754 floating-point formats, it is often the case that an infinitely precise result cannot be encoded exactly 
in the format of the destination operand. 


For example, the following value (a) has a 24-bit fraction. The least-significant bit of this fraction (the underlined 
bit) cannot be encoded exactly in the single-precision format (which has only a 23-bit fraction): 


(a) 1.0001 0000 1000 0011 1001 0111E, 101 


To round this result (a), the processor first selects two representable fractions b and c that most closely bracket a 
in value (b<a<c). 


(b) 1.0001 0000 1000 0011 1001 011E, 101 
(c) 1.0001 0000 1000 0011 1001 100E, 101 


The processor then sets the result to b or to c according to the selected rounding mode. Rounding introduces an 
error in a result that is less than one unit in the last place (the least significant bit position of the floating-point 
value) to which the result is rounded. 
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The IEEE Standard 754 defines four rounding modes (see Table 4-8): round to nearest, round up, round down, and 
round toward zero. The default rounding mode (for the Intel 64 and IA-32 architectures) is round to nearest. This 
mode provides the most accurate and statistically unbiased estimate of the true result and is suitable for most 
applications. 


Table 4-8. Rounding Modes and Encoding of Rounding Control (RC) Field 


Rounding Mode RC Field Description 
Setting 
Round to OOB Rounded result is the closest to the infinitely precise result. If two values are equally close, the 
nearest (even) result is the even value (that is, the one with the least-significant bit of zero). Default 
Round down 01B Rounded result is closest to but no greater than the infinitely precise result. 
(toward —co) 
Round up 10B Rounded result is closest to but no less than the infinitely precise result. 
(toward +co) 
Round toward 11B Rounded result is closest to but no greater in absolute value than the infinitely precise result. 
zero (Truncate) 


The round up and round down modes are termed directed rounding and can be used to implement interval arith- 
metic. Interval arithmetic is used to determine upper and lower bounds for the true result of a multistep computa- 
tion, when the intermediate results of the computation are subject to rounding. 


The round toward zero mode (sometimes called the “chop” mode) is commonly used when performing integer 
arithmetic with the x87 FPU. 


The rounded result is called the inexact result. When the processor produces an inexact result, the floating-point 
precision (inexact) flag (PE) is set (see Section 4.9.1.6, “Inexact-Result (Precision) Exception (#P)”). 


The rounding modes have no effect on comparison operations, operations that produce exact results, or operations 
that produce NaN results. 


4.8.4.1 Rounding Control (RC) Fields 


In the Intel 64 and IA-32 architectures, the rounding mode is controlled by a 2-bit rounding-control (RC) field 
(Table 4-8 shows the encoding of this field). The RC field is implemented in two different locations: 


¢ x87 FPU control register (bits 10 and 11) 
° The MXCSR register (bits 13 and 14) 


Although these two RC fields perform the same function, they control rounding for different execution environ- 
ments within the processor. The RC field in the x87 FPU control register controls rounding for computations 
performed with the x87 FPU instructions; the RC field in the MXCSR register controls rounding for SIMD floating- 
point computations performed with the SSE/SSE2 instructions. 


4.8.4.2 Truncation with SSE and SSE2 Conversion Instructions 


The following SSE/SSE2 instructions automatically truncate the results of conversions from floating-point values to 
integers when the result it inexact: CVTTPD2DQ, CVTTPS2DQ, CVTTPD2PI, CVTTPS2PI, CVTTSD2SI, CVTTSS2SI. 
Here, truncation means the round toward zero mode described in Table 4-8. 


4.9 OVERVIEW OF FLOATING-POINT EXCEPTIONS 


The following section provides an overview of floating-point exceptions and their handling in the IA-32 architecture. 
For information specific to the x87 FPU and to the SSE/SSE2/SSE3/SSE4.1 extensions, refer to the following 
sections: 


° Section 8.4, “x87 FPU Floating-Point Exception Handling” 


4-18 Vol.1 


DATA TYPES 


® Section 11.5, “SSE, SSE2, and SSE3 Exceptions” 


When operating on floating-point operands, the IA-32 architecture recognizes and detects six classes of exception 
conditions: 


¢ Invalid operation (#1) 

* Divide-by-zero (#Z) 

¢ Denormalized operand (#D) 

¢ Numeric overflow (#0) 

¢ Numeric underflow (#U) 

¢  Inexact result (precision) (#P) 


The nomenclature of “#” symbol followed by one or two letters (for example, #P) is used in this manual to indicate 
exception conditions. It is merely a short-hand form and is not related to assembler mnemonics. 


NOTE 


All of the exceptions listed above except the denormal-operand exception (#D) are defined in IEEE 
Standard 754. 


The invalid-operation, divide-by-zero and denormal-operand exceptions are pre-computation exceptions (that is, 
they are detected before any arithmetic operation occurs). The numeric-underflow, numeric-overflow and precision 
exceptions are post-computation exceptions. 


Each of the six exception classes has a corresponding flag bit (IE, ZE, OE, UE, DE, or PE) and mask bit (IM, ZM, OM, 
UM, DM, or PM). When one or more floating-point exception conditions are detected, the processor sets the appro- 
priate flag bits, then takes one of two possible courses of action, depending on the settings of the corresponding 
mask bits: 


¢ Mask bit set. Handles the exception automatically, producing a predefined (and often times usable) result, 
while allowing program execution to continue undisturbed. 


¢ Mask bit clear. Invokes a software exception handler to handle the exception. 


The masked (default) responses to exceptions have been chosen to deliver a reasonable result for each exception 
condition and are generally satisfactory for most floating-point applications. By masking or unmasking specific 
floating-point exceptions, programmers can delegate responsibility for most exceptions to the processor and 
reserve the most severe exception conditions for software exception handlers. 


Because the exception flags are “sticky,” they provide a cumulative record of the exceptions that have occurred 
since they were last cleared. A programmer can thus mask all exceptions, run a calculation, and then inspect the 
exception flags to see if any exceptions were detected during the calculation. 


In the IA-32 architecture, floating-point exception flag and mask bits are implemented in two different locations: 


¢ x87 FPU status word and control word. The flag bits are located at bits 0 through 5 of the x87 FPU status word 
and the mask bits are located at bits 0 through 5 of the x87 FPU control word (see Figures 8-4 and 8-6). 


¢ MXCSR register. The flag bits are located at bits 0 through 5 of the MXCSR register and the mask bits are 
located at bits 7 through 12 of the register (see Figure 10-3). 


Although these two sets of flag and mask bits perform the same function, they report on and control exceptions for 
different execution environments within the processor. The flag and mask bits in the x87 FPU status and control 
words control exception reporting and masking for computations performed with the x87 FPU instructions; the 
companion bits in the MXCSR register control exception reporting and masking for SIMD floating-point computa- 
tions performed with the SSE/SSE2/SSE3 instructions. 


Note that when exceptions are masked, the processor may detect multiple exceptions in a single instruction, 
because it continues executing the instruction after performing its masked response. For example, the processor 
can detect a denormalized operand, perform its masked response to this exception, and then detect numeric 
underflow. 


See Section 4.9.2, “Floating-Point Exception Priority,” for a description of the rules for exception precedence when 
more than one floating-point exception condition is detected for an instruction. 
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4.9.1 Floating-Point Exception Conditions 


The following sections describe the various conditions that cause a floating-point exception to be generated and the 
masked response of the processor when these conditions are detected. The Inte/® 64 and IA-32 Architectures 
Software Developer’s Manual, Volumes 3A & 3B, list the floating-point exceptions that can be signaled for each 
floating-point instruction. 


4.9.1.1 Invalid Operation Exception (#1) 


The processor reports an invalid operation exception in response to one or more invalid arithmetic operands. If the 
invalid operation exception is masked, the processor sets the IE flag and returns an indefinite value or a QNaN. This 
value overwrites the destination register specified by the instruction. If the invalid operation exception is not 
masked, the IE flag is set, a software exception handler is invoked, and the operands remain unaltered. 


See Section 4.8.3.6, “Using SNaNs and QNaNs in Applications,” for information about the result returned when an 
exception is caused by an SNaN. 


The processor can detect a variety of invalid arithmetic operations that can be coded in a program. These opera- 

tions generally indicate a programming error, such as dividing - by «. See the following sections for information 
regarding the invalid-operation exception when detected while executing x87 FPU or SSE/SSE2/SSE3/SSE4.1 or 

AVX instructions: 


°® x87 FPU; Section 8.5.1, “Invalid Operation Exception”. 
¢ SIMD floating-point exceptions; Section 11.5.2.1, “Invalid Operation Exception (#1)”. 


4.9.1.2 Denormal Operand Exception (#D) 


The processor reports the denormal-operand exception if an arithmetic instruction attempts to operate ona 
denormal operand (see Section 4.8.3.2, “Normalized and Denormalized Finite Numbers”). When the exception is 
masked, the processor sets the DE flag and proceeds with the instruction. Operating on denormal numbers will 
produce results at least as good as, and often better than, what can be obtained when denormal numbers are 
flushed to zero. Programmers can mask this exception so that a computation may proceed, then analyze any loss 
of accuracy when the final result is delivered. 


When a denormal-operand exception is not masked, the DE flag is set, a software exception handler is invoked, and 
the operands remain unaltered. When denormal operands have reduced significance due to loss of low-order bits, 
it may be advisable to not operate on them. Precluding denormal operands from computations can be accom- 
plished by an exception handler that responds to unmasked denormal-operand exceptions. 


See the following sections for information regarding the denormal-operand exception when detected while 
executing x87 FPU or SSE/SSE2/SSE3 instructions: 


° x87 FPU; Section 8.5.2, “Denormal Operand Exception (#D)”. 
¢ SIMD floating-point exceptions; Section 11.5.2.2, ‘Denormal-Operand Exception (#D)”. 


4.9.1.3 Divide-By-Zero Exception (#Z) 


The processor reports the floating-point divide-by-zero exception whenever an instruction attempts to divide a 
finite non-zero operand by 0. The masked response for the divide-by-zero exception is to set the ZE flag and return 
an infinity signed with the exclusive OR of the sign of the operands. If the divide-by-zero exception is not masked, 
the ZE flag is set, a software exception handler is invoked, and the operands remain unaltered. 


See the following sections for information regarding the divide-by-zero exception when detected while executing 
x87 FPU or SSE/SSE2 instructions: 


° x87 FPU; Section 8.5.3, “Divide-By-Zero Exception (#Z)”. 
¢ SIMD floating-point exceptions; Section 11.5.2.3, “Divide-By-Zero Exception (#Z)”. 
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4.9.1.4 Numeric Overflow Exception (#0) 


The processor reports a floating-point numeric overflow exception whenever the rounded result of an instruction 
exceeds the largest allowable finite value that will fit into the destination operand. Table 4-9 shows the threshold 
range for numeric overflow for each of the floating-point formats; overflow occurs when a rounded result falls at or 
outside this threshold range. 


Table 4-9. Numeric Overflow Thresholds 


Floating-Point Format Overflow Thresholds 
Single Precision |x]>1.0 «2128 
Double Precision |x| > 1.0 «21024 
Double Extended Precision |x| > 1.0 « 216384 


When a numeric-overflow exception occurs and the exception is masked, the processor sets the OE flag and 
returns one of the values shown in Table 4-10, according to the current rounding mode. See Section 4.8.4, 
“Rounding.” 


When numeric overflow occurs and the numeric-overflow exception is not masked, the OE flag is set, a software 
exception handler is invoked, and the source and destination operands either remain unchanged or a biased result 
is stored in the destination operand (depending whether the overflow exception was generated during an 
SSE/SSE2/SSE3 floating-point operation or an x87 FPU operation). 


Table 4-10. Masked Responses to Numeric Overflow 


Rounding Mode Sign of True Result Result 
To nearest + too 
Toward -co + Largest finite positive number 
Toward +o + too 
- Largest finite negative number 
Toward zero + Largest finite positive number 
- Largest finite negative number 


See the following sections for information regarding the numeric overflow exception when detected while executing 
x87 FPU instructions or while executing SSE/SSE2/SSE3 instructions: 


° x87 FPU; Section 8.5.4, “Numeric Overflow Exception (#0)” 
¢ SIMD floating-point exceptions; Section 11.5.2.4, “Numeric Overflow Exception (#0)” 


4.9.1.5 Numeric Underflow Exception (#U) 


The processor detects a potential floating-point numeric underflow condition whenever the result of rounding with 
unbounded exponent (taking into account precision control for x87) is non-zero and tiny; that is, non-zero and less 
than the smallest possible normalized, finite value that will fit into the destination operand. Table 4-11 shows the 
threshold range for numeric underflow for each of the floating-point formats (assuming normalized results); 
underflow occurs when a rounded result falls strictly within the threshold range. The ability to detect and handle 
underflow is provided to prevent a very small result from propagating through a computation and causing another 
exception (such as overflow during division) to be generated at a later time. Results which trigger underflow are 
also potentially less accurate. 
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Table 4-11. Numeric Underflow (Normalized) Thresholds 


Floating-Point Format Underflow Thresholds* 
Single Precision [x] <1.0 «2-126 
Double Precision 1x |< 1.0 «21022 
Double Extended Precision |x |< 1.0 * 2- 16382 


* Where ‘x’ is the result rounded to destination precision with an unbounded exponent range. 


How the processor handles an underflow condition, depends on two related conditions: 
* creation of a tiny, non-zero result 
* creation of an inexact result; that is, a result that cannot be represented exactly in the destination format 


Which of these events causes an underflow exception to be reported and how the processor responds to the excep- 
tion condition depends on whether the underflow exception is masked: 


° Underflow exception masked — The underflow exception is reported (the UE flag is set) only when the result 
is both tiny and inexact. The processor returns a correctly signed result whose magnitude is less than or equal 
to the smallest positive normal floating-point number to the destination operand, regardless of inexactness. 


¢ Underflow exception not masked — The underflow exception is reported when the result is non-zero tiny, 
regardless of inexactness. The processor leaves the source and destination operands unaltered or stores a 
biased result in the destination operand (depending whether the underflow exception was generated during an 
SSE/SSE2/SSE3 floating-point operation or an x87 FPU operation) and invokes a software exception handler. 


See the following sections for information regarding the numeric underflow exception when detected while 
executing x87 FPU instructions or while executing SSE/SSE2/SSE3 instructions: 


° x87 FPU; Section 8.5.5, “Numeric Underflow Exception (#U)” 
¢ SIMD floating-point exceptions; Section 11.5.2.5, “Numeric Underflow Exception (#U)” 


4.9.1.6 Inexact-Result (Precision) Exception (#P) 


The inexact-result exception (also called the precision exception) occurs if the result of an operation is not exactly 
representable in the destination format. For example, the fraction 1/3 cannot be precisely represented in binary 
floating-point form. This exception occurs frequently and indicates that some (normally acceptable) accuracy will 
be lost due to rounding. The exception is supported for applications that need to perform exact arithmetic only. 
Because the rounded result is generally satisfactory for most applications, this exception is commonly masked. 


If the inexact-result exception is masked when an inexact-result condition occurs and a numeric overflow or under- 
flow condition has not occurred, the processor sets the PE flag and stores the rounded result in the destination 
operand. The current rounding mode determines the method used to round the result. See Section 4.8.4, 
“Rounding.” 


If the inexact-result exception is not masked when an inexact result occurs and numeric overflow or underflow has 
not occurred, the PE flag is set, the rounded result is stored in the destination operand, and a software exception 
handler is invoked. 


If an inexact result occurs in conjunction with numeric overflow or underflow, one of the following operations is 
carried out: 


¢ If an inexact result occurs along with masked overflow or underflow, the OE flag or UE flag and the PE flag are 
set and the result is stored as described for the overflow or underflow exceptions; see Section 4.9.1.4, 
“Numeric Overflow Exception (#0),” or Section 4.9.1.5, “Numeric Underflow Exception (#U).” If the inexact 
result exception is unmasked, the processor also invokes a software exception handler. 


¢ If an inexact result occurs along with unmasked overflow or underflow and the destination operand is a register, 
the OE or UE flag and the PE flag are set, the result is stored as described for the overflow or underflow 
exceptions, and a software exception handler is invoked. 


If an unmasked numeric overflow or underflow exception occurs and the destination operand is a memory location 
(which can happen only for a floating-point store), the inexact-result condition is not reported and the C1 flag is 
cleared. 
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See the following sections for information regarding the inexact-result exception when detected while executing 
x87 FPU or SSE/SSE2/SSE3 instructions: 


° x87 FPU; Section 8.5.6, “Inexact-Result (Precision) Exception (#P)” 
¢ SIMD floating-point exceptions; Section 11.5.2.3, “Divide-By-Zero Exception (#Z)” 


4.9.2 Floating-Point Exception Priority 


The processor handles exceptions according to a predetermined precedence. When an instruction generates two or 
more exception conditions, the exception precedence sometimes results in the higher-priority exception being 
handled and the lower-priority exceptions being ignored. For example, dividing an SNaN by zero can potentially 
signal an invalid-operation exception (due to the SNaN operand) and a divide-by-zero exception. Here, if both 
exceptions are masked, the processor handles the higher-priority exception only (the invalid-operation exception), 
returning a QNaN to the destination. Alternately, a denormal-operand or inexact-result exception can accompany 
a numeric underflow or overflow exception with both exceptions being handled. 


The precedence for floating-point exceptions is as follows: 
1. Invalid-operation exception, subdivided as follows: 

a. stack underflow (occurs with x87 FPU only) 

b. stack overflow (occurs with x87 FPU only) 


c. operand of unsupported format (occurs with x87 FPU only when using the double extended-precision 
floating-point format) 


d. SNaN operand 


2. QNaN operand. Though this is not an exception, the handling of a QNaN operand has precedence over lower- 
priority exceptions. For example, a QNaN divided by zero results in a QNaN, not a zero-divide exception. 


3. Any other invalid-operation exception not mentioned above or a divide-by-zero exception. 


Denormal-operand exception. If masked, then instruction execution continues and a lower-priority exception 
can occur as well. 


5. Numeric overflow and underflow exceptions; possibly in conjunction with the inexact-result exception. 
6. Inexact-result exception. 


Invalid operation, zero divide, and denormal operand exceptions are detected before a floating-point operation 
begins. Overflow, underflow, and precision exceptions are not detected until a true result has been computed. 
When an unmasked pre-operation exception is detected, the destination operand has not yet been updated, and 
appears as if the offending instruction has not been executed. When an unmasked post-operation exception is 
detected, the destination operand may be updated with a result, depending on the nature of the exception (except 
for SSE/SSE2/SSE3 instructions, which do not update their destination operands in such cases). 


4.9.3 Typical Actions of a Floating-Point Exception Handler 


After the floating-point exception handler is invoked, the processor handles the exception in the same manner that 
it handles non-floating-point exceptions. The floating-point exception handler is normally part of the operating 
system or executive software, and it usually invokes a user-registered floating-point exception handle. 


A typical action of the exception handler is to store state information in memory. Other typical exception handler 
actions include: 


¢ Examining the stored state information to determine the nature of the error 

¢ Taking actions to correct the condition that caused the error 

°* Clearing the exception flags 

¢ Returning to the interrupted program and resuming normal execution 

In lieu of writing recovery procedures, the exception handler can do the following: 
¢ Increment in software an exception counter for later display or printing 
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¢ Print or display diagnostic information (such as the state information) 
° Halt further program execution 
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INSTRUCTION SET SUMMARY 


This chapter provides an abridged overview of Intel 64 and IA-32 instructions. Instructions are divided into the 
following groups: 


® Section 5.1, “General-Purpose Instructions”. 

® Section 5.2, “x87 FPU Instructions”. 

* Section 5.3, “x87 FPU AND SIMD State Management Instructions”. 

° Section 5.4, “MMX™ Instructions”. 

® Section 5.5, “SSE Instructions”. 

*® Section 5.6, “SSE2 Instructions”. 

® Section 5.7, “SSE3 Instructions”. 

® Section 5.8, “Supplemental Streaming SIMD Extensions 3 (SSSE3) Instructions”. 
® Section 5.9, “SSE4 Instructions”. 

® Section 5.10, “SSE4.1 Instructions”. 

® Section 5.11, “SSE4.2 Instruction Set”. 

* Section 5.12, “Intel® AES-NI and PCLMULQDQ”. 

* Section 5.13, “Intel® Advanced Vector Extensions (Intel® AVX)”. 

* Section 5.14, “16-bit Floating-Point Conversion”. 

°* Section 5.15, “Fused-Multiply-ADD (FMA)”. 

° Section 5.16, “Intel® Advanced Vector Extensions 2 (Intel® AVX2)”. 

* Section 5.17, “Intel® Transactional Synchronization Extensions (Intel® TSX)”. 
* Section 5.18, “Intel® SHA Extensions”. 

° Section 5.19, “Intel® Advanced Vector Extensions 512 (Intel® AVX-512)”. 
° Section 5.20, “System Instructions”. 

® Section 5.21, “64-Bit Mode Instructions”. 

® Section 5.22, “Virtual-Machine Extensions”. 

® Section 5.23, “Safer Mode Extensions”. 

® Section 5.24, “Intel® Memory Protection Extensions”. 

® Section 5.25, “Intel® Software Guard Extensions”. 

® Section 5.26, “Shadow Stack Management Instructions”. 

° Section 5.27, “Control Transfer Terminating Instructions”. 


Table 5-1 lists the groups and IA-32 processors that support each group. More recent instruction set extensions are 
listed in Table 5-2. Within these groups, most instructions are collected into functional subgroups. 


Table 5-1. Instruction Groups in Intel 64 and IA-32 Processors 


Instruction Set 


Architecture Intel 64 and IA-32 Processor Support 
General Purpose All Intel 64 and IA-32 processors. 
x87 FPU Intel486, Pentium, Pentium with MMX Technology, Celeron, Pentium Pro, Pentium II, Pentium II Xeon, 


Pentium Ill, Pentium Ill Xeon, Pentium 4, Intel Xeon processors, Pentium M, Intel Core Solo, Intel Core Duo, 
Intel Core 2 Duo processors, Intel Atom processors. 


x87 FPU and SIMD State | Pentium II, Pentium II Xeon, Pentium Ill, Pentium Ill Xeon, Pentium 4, Intel Xeon processors, Pentium M, 
Management Intel Core Solo, Intel Core Duo, Intel Core 2 Duo processors, Intel Atom processors. 
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Table 5-1. Instruction Groups in Intel 64 and IA-32 Processors (Contd.) 


Instruction Set 
Architecture 


Intel 64 and IA-32 Processor Support 


MMX Technology 


Pentium with MMX Technology, Celeron, Pentium I, Pentium II Xeon, Pentium Ill, Pentium Ill Xeon, Pentium 
4, Intel Xeon processors, Pentium M, Intel Core Solo, Intel Core Duo, Intel Core 2 Duo processors, Intel Atom 
processors. 


SSE Extensions 


Pentium Ill, Pentium Ill Xeon, Pentium 4, Intel Xeon processors, Pentium M, Intel Core Solo, Intel Core Duo, 
Intel Core 2 Duo processors, Intel Atom processors. 


SSE2 Extensions 


Pentium 4, Intel Xeon processors, Pentium M, Intel Core Solo, Intel Core Duo, Intel Core 2 Duo processors, 
Intel Atom processors. 


SSE3 Extensions 


Pentium 4 supporting HT Technology (built on 90nm process technology), Intel Core Solo, Intel Core Duo, 
Intel Core 2 Duo processors, Intel Xeon processor 3Xxxx, 5Xxx, 7Xxx Series, Intel Atom processors. 


SSSE3 Extensions 


Intel Xeon processor 3xxx, 5100, 5200, 5300, 5400, 5500, 5600, 7300, 7400, 7500 series, Intel Core 2 
Extreme processors QX6000 series, Intel Core 2 Duo, Intel Core 2 Quad processors, Intel Pentium Dual-Core 
processors, Intel Atom processors. 


IA-32e mode: 64-bit 
mode instructions 


Intel 64 processors. 


System Instructions 


Intel 64 and IA-32 processors. 


VMX Instructions 


Intel 64 and IA-32 processors supporting Intel Virtualization Technology. 


SMX Instructions 


Intel Core 2 Duo processor E6x50, E8xxx; Intel Core 2 Quad processor Q9xxx. 


Table 5-2. Instruction Set Extensions Introduction in Intel 64 and IA-32 Processors 


Instruction Set 
Architecture 


Processor Generation Introduction 


SSE4.1 Extensions 


Intel® Xeon® processor 3100, 3300, 5200, 5400, 7400, 7500 series, Intel® Core™ 2 Extreme processors 
QX9000 series, Intel® Core™ 2 Quad processor Q9000 series, Intel® Core™ 2 Duo processors 8000 series 
and T9000 series, Intel Atom® processor based on Silvermont microarchitecture. 


SSE4.2 Extensions, 
CRC32, POPCNT 


Intel® Core™ i7 965 processor, Intel’ Xeon® processors X3400, X3500, X5500, X6500, X7500 series, 
Intel Atom processor based on Silvermont microarchitecture. 


Intel® AES-NI, Intel® Xeon® processor E7 series, Intel’ Xeon® processors X3600 and X5600, Intel® Core™ i7 980X 

PCLMULQDQ processor, Intel Atom processor based on Silvermont microarchitecture. Use CPUID to verify presence of 
Intel AES-NI and PCLMULQDQ across Intel® Core™ processor families. 

Intel? AVX Intel® Xeon® processor E3 and E5 families, 2nd Generation Intel® Core™ i7, i5, i3 processor 2xxx families. 

F16C 3rd Generation Intel® Core™ processors, Intel® Xeon® processor E3-1200 v2 product family, Intel® Xeon® 
processor E5 v2 and €7 v2 families. 

RDRAND 3rd Generation Intel Core processors, Intel Xeon processor €3-1200 v2 product family, Intel Xeon 


processor E5 v2 and €7 v2 families, Intel Atom processor based on Silvermont microarchitecture. 


FS/GS base access 


3rd Generation Intel Core processors, Intel Xeon processor €3-1200 v2 product family, Intel Xeon 
processor E5 v2 and €7 v2 families, Intel Atom® processor based on Goldmont microarchitecture. 


FMA, AVX2, BMI1, BMI2, 
INVPCID, LZCNT, Intel® 
TSX 


Intel® Xeon® processor €3/E5/E7 v3 product families, 4th Generation Intel® Core™ processor family. 


MOVBE Intel Xeon processor €3/E5/E7 v3 product families, 4th Generation Intel Core processor family, Intel Atom 
processors. 
PREFETCHW Intel® Core™ M processor family; 5th Generation Intel® Core™ processor family, Intel Atom processor based 


on Silvermont microarchitecture. 


5-2 Vol.1 


INSTRUCTION SET SUMMARY 


Table 5-2. Instruction Set Extensions Introduction in Intel 64 and IA-32 Processors (Contd.) 


Instruction Set 
Architecture 


Processor Generation Introduction 


ADX 


Intel Core M processor family, 5th Generation Intel Core processor family. 


RDSEED, CLAC, STAC 


Intel Core M processor family, 5th Generation Intel Core processor family, Intel Atom processor based on 
Goldmont microarchitecture. 


AVX512ER, AVX512PF, 
PREFETCHWT 1 


Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series. 


AVX512F, AVX512CD 


Intel Xeon Phi Processor 3200, 5200, 7200 Series, Intel® Xeon® Processor Scalable Family, Intel® Core™ i3- 
8121U processor. 


CLFLUSHOPT, XSAVEC, 
XSAVES, Intel®? MPX 


Intel Xeon Processor Scalable Family, 6th Generation Intel® Core™ processor family, Intel Atom processor 
based on Goldmont microarchitecture. 


SGX1 


6th Generation Intel Core processor family, Intel Atom® processor based on Goldmont Plus 
microarchitecture. 


AVX512DQ, AVX512BW, 
AVX512VL 


Intel Xeon Processor Scalable Family, Intel Core i3-8121U processor based on Cannon Lake 
microarchitecture. 


CLWB Intel Xeon Processor Scalable Family, Intel Atom® processor based on Tremont microarchitecture, 11th 
Generation Intel Core processor family based on Tiger Lake microarchitecture. 

PKU Intel Xeon Processor Scalable Family, 10th generation Intel® Core™ processors based on Comet Lake 
microarchitecture. 

AVX512_IFMA, Intel Core i3-8121U processor based on Cannon Lake microarchitecture. 

AVX512_VBMI 


Intel® SHA Extensions 


Intel Core i3-8121U processor based on Cannon Lake microarchitecture , Intel Atom processor based on 
Goldmont microarchitecture, 3rd Generation Intel® Xeon® Processor Scalable Family based on Ice Lake 
microarchitecture. 


UMIP Intel Core i3-8121U processor based on Cannon Lake microarchitecture, Intel Atom processor based on 
Goldmont Plus microarchitecture. 

PTWRITE Intel Atom processor based on Goldmont Plus microarchitecture. 

RDPID 10th Generation Intel® Core™ processor family based on Ice Lake microarchitecture, Intel Atom processor 


based on Goldmont Plus microarchitecture. 


AVX512_4FMAPS, 
AVX512_4VNNIW 


AVX512_VNNI 


Intel? Xeon Phi™ Processor 7215, 7285, 7295 Series. 


2nd Generation Intel® Xeon® Processor Scalable Family, 10th Generation Intel Core processor family based 
on Ice Lake microarchitecture. 


AVX512_VPOPCNTDQ 


Intel Xeon Phi Processor 7215, 7285, 7295 Series, 10th Generation Intel Core processor family based on 
Ice Lake microarchitecture. 


Fast Short REP MOV 10th Generation Intel Core processor family based on Ice Lake microarchitecture. 

GFNI (SSE) 10th Generation Intel Core processor family based on Ice Lake microarchitecture, Intel Atom processor 
based on Tremont microarchitecture. 

VAES, 10th Generation Intel Core processor family based on Ice Lake microarchitecture. 


GFNI (AVX/AVX51 2), 
AVX512_VBMIe2, 
VPCLMULQDQ, 
AVX512_BITALG 


ENCLV 


Intel Atom processor based on Tremont microarchitecture, 3rd Generation Intel® Xeon® Processor Scalable 
Processors based on Ice Lake microarchitecture. 


Split Lock Detection 


10th Generation Intel Core processor family based on Ice Lake microarchitecture, Intel Atom processor 
based on Tremont microarchitecture. 
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Table 5-2. Instruction Set Extensions Introduction in Intel 64 and IA-32 Processors (Contd.) 
Instruction Set 


Architecture Processor Generation Introduction 

CLDEMOTE Intel Atom processor based on Tremont microarchitecture. 

Direct stores: MOVDIRI, Intel Atom processor based on Tremont microarchitecture, 11th Generation Intel Core processor family 
MOVDIR64B based on Tiger Lake microarchitecture. 

User wait: TPAUSE, Intel Atom processor based on Tremont microarchitecture. 

UMONITOR, UMWAIT 

AVX512_BF16 3rd Generation Intel® Xeon® Processor Scalable Processors based on Cooper Lake product. 


AVX512_VP2INTERSECT | 11th Generation Intel Core processor family based on Tiger Lake microarchitecture. 


Key Locker! 11th Generation Intel Core processor family based on Tiger Lake microarchitecture. 


Control-flow Enforcement | 11th Generation Intel Core processor family based on Tiger Lake microarchitecture. 
Technology (CET) 


MKTME2, PCONFIG 3rd Generation Intel® Xeon® Processor Scalable Family based on Ice Lake microarchitecture. 
WBNOINVD 3rd Generation Intel® Xeon® Processor Scalable Family based on Ice Lake microarchitecture. 
Supervisor Memory Future Intel processors 

Protection Keys (PKS) 
NOTES: 


1. Details on Key Locker can be found in the Intel Key Locker Specification here: 
https://software.intel.com/content/www/us/en/develop/download/intel-key-locker-specification.html. 

2. Further details on MKTME usage can be found here: 
https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-Total-Memory-Encryption-Spec.pdf. 


The following sections list instructions in each major group and subgroup. Given for each instruction is its 
mnemonic and descriptive names. When two or more mnemonics are given (for example, CMOVA/CMOVNBE), they 
represent different mnemonics for the same instruction opcode. Assemblers support redundant mnemonics for 
some instructions to make it easier to read code listings. For instance, CMOVA (Conditional move if above) and 
CMOVNBE (Conditional move if not below or equal) represent the same condition. For detailed information about 
specific instructions, see the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A, 2B, 2C 
& 2D. 


5.1 GENERAL-PURPOSE INSTRUCTIONS 


The general-purpose instructions perform basic data movement, arithmetic, logic, program flow, and string opera- 
tions that programmers commonly use to write application and system software to run on Intel 64 and IA-32 
processors. They operate on data contained in memory, in the general-purpose registers (EAX, EBX, ECX, EDX, 
EDI, ESI, EBP, and ESP) and in the EFLAGS register. They also operate on address information contained in 
memory, the general-purpose registers, and the segment registers (CS, DS, SS, ES, FS, and GS). 


This group of instructions includes the data transfer, binary integer arithmetic, decimal arithmetic, logic operations, 
shift and rotate, bit and byte operations, program control, string, flag control, segment register operations, and 
miscellaneous subgroups. The sections that follow introduce each subgroup. 


For more detailed information on general purpose-instructions, see Chapter 7, “Programming With General- 
Purpose Instructions.” 


5.1.1 Data Transfer Instructions 


The data transfer instructions move data between memory and the general-purpose and segment registers. They 
also perform specific operations such as conditional moves, stack access, and data conversion. 
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MOV 


CMOVE/CMOVZ 
CMOVNE/CMOVNZ 
CMOVA/CMOVNBE 
CMOVAE/CMOVNB 
CMOVB/CMOVNAE 
CMOVBE/CMOVNA 
CMOVG/CMOVNLE 
CMOVGE/CMOVNL 
CMOVL/CMOVNGE 
CMOVLE/CMOVNG 
CMOVC 

CMOVNC 

CMOVO 

CMOVNO 

CMOVS 

CMOVNS 
CMOVP/CMOVPE 
CMOVNP/CMOVPO 
XCHG 

BSWAP 

XADD 

CMPXCHG 
CMPXCHG8B 
PUSH 

POP 
PUSHA/PUSHAD 
POPA/POPAD 
CWD/CDQ 
CBW/CWDE 
MOVSX 

MOVZX 


5.1.2 


INSTRUCTION SET SUMMARY 


Move data between general-purpose registers; move data between memory and general- 
purpose or segment registers; move immediates to general-purpose registers. 


Conditional move if equal/Conditional move if zero. 

Conditional move if not equal/Conditional move if not zero. 
Conditional move if above/Conditional move if not below or equal. 
Conditional move if above or equal/Conditional move if not below. 
Conditional move if below/Conditional move if not above or equal. 
Conditional move if below or equal/Conditional move if not above. 
Conditional move if greater/Conditional move if not less or equal. 
Conditional move if greater or equal/Conditional move if not less. 
Conditional move if less/Conditional move if not greater or equal. 
Conditional move if less or equal/Conditional move if not greater. 
Conditional move if carry. 

Conditional move if not carry. 

Conditional move if overflow. 

Conditional move if not overflow. 

Conditional move if sign (negative). 

Conditional move if not sign (non-negative). 

Conditional move if parity/Conditional move if parity even. 
Conditional move if not parity/Conditional move if parity odd. 
Exchange. 

Byte swap. 

Exchange and add. 

Compare and exchange. 

Compare and exchange 8 bytes. 

Push onto stack. 

Pop off of stack. 

Push general-purpose registers onto stack. 

Pop general-purpose registers from stack. 

Convert word to doubleword/Convert doubleword to quadword. 
Convert byte to word/Convert word to doubleword in EAX register. 
Move and sign extend. 

Move and zero extend. 


Binary Arithmetic Instructions 


The binary arithmetic instructions perform basic binary integer computations on byte, word, and doubleword inte- 
gers located in memory and/or the general purpose registers. 


ADCX 
ADOX 
ADD 
ADC 
SUB 
SBB 
IMUL 
MUL 
IDIV 


Unsigned integer add with carry. 
Unsigned integer add with overflow. 
Integer add. 

Add with carry. 

Subtract. 

Subtract with borrow. 

Signed multiply. 

Unsigned multiply. 

Signed divide. 
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DIV Unsigned divide. 
INC Increment. 

DEC Decrement. 
NEG Negate. 

CMP Compare. 


A Decimal Arithmetic Instructions 


The decimal arithmetic instructions perform decimal arithmetic on binary coded decimal (BCD) data. 


DAA Decimal adjust after addition. 
DAS Decimal adjust after subtraction. 
AAA ASCII adjust after addition. 

AAS ASCII adjust after subtraction. 
AAM ASCII adjust after multiplication. 
AAD ASCII adjust before division. 


5.1.4 Logical Instructions 


The logical instructions perform basic AND, OR, XOR, and NOT logical operations on byte, word, and doubleword 
values. 


AND Perform bitwise logical AND. 

OR Perform bitwise logical OR. 

XOR Perform bitwise logical exclusive OR. 
NOT Perform bitwise logical NOT. 


5.1.5 Shift and Rotate Instructions 


The shift and rotate instructions shift and rotate the bits in word and doubleword operands. 
SAR Shift arithmetic right. 


SHR Shift logical right. 

SAL/SHL Shift arithmetic left/Shift logical left. 
SHRD Shift right double. 

SHLD Shift left double. 

ROR Rotate right. 

ROL Rotate left. 

RCR Rotate through carry right. 

RCL Rotate through carry left. 


5.1.6 Bit and Byte Instructions 


Bit instructions test and modify individual bits in word and doubleword operands. Byte instructions set the value of 
a byte operand to indicate the status of flags in the EFLAGS register. 


BT Bit test. 

BTS Bit test and set. 

BIR Bit test and reset. 

BIC Bit test and complement. 
BSF Bit scan forward. 
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BSR 
SETE/SETZ 
SETNE/SETNZ 
SETA/SETNBE 


INSTRUCTION SET SUMMARY 


Bit scan reverse. 

Set byte if equal/Set byte if zero. 

Set byte if not equal/Set byte if not zero. 

Set byte if above/Set byte if not below or equal. 


SETAE/SETNB/SETNC Set byte if above or equal/Set byte if not below/Set byte if not carry. 


SETB/SETNAE/SETC 


SETBE/SETNA 
SETG/SETNLE 
SETGE/SETNL 
SETL/SETNGE 
SETLE/SETNG 
SETS 

SETNS 

SETO 

SETNO 
SETPE/SETP 
SETPO/SETNP 
TEST 

CRC32! 


POPCNT2 


Set byte if below/Set byte if not above or equal/Set byte if carry. 

Set byte if below or equal/Set byte if not above. 

Set byte if greater/Set byte if not less or equal. 

Set byte if greater or equal/Set byte if not less. 

Set byte if less/Set byte if not greater or equal. 

Set byte if less or equal/Set byte if not greater. 

Set byte if sign (negative). 

Set byte if not sign (non-negative). 

Set byte if overflow. 

Set byte if not overflow. 

Set byte if parity even/Set byte if parity. 

Set byte if parity odd/Set byte if not parity. 

Logical compare. 

Provides hardware acceleration to calculate cyclic redundancy checks for fast and efficient 
implementation of data integrity protocols. 

This instruction calculates of number of bits set to 1 in the second operand (source) and 
returns the count in the first operand (a destination register). 


5.1.7 Control Transfer Instructions 


The control transfer instructions provide jump, conditional jump, loop, and call and return operations to control 


program flow. 
JMP 
JE/IZ 
JNE/INZ 
JA/INBE 
JAE/JINB 
JB/JNAE 
JBE/JNA 
JG/JNLE 
JGE/JNL 
JL/INGE 
JLE/JING 
JC 

INC 

JO 

JNO 

JS 

JNS 


Jump. 

Jump if equal/Jump if zero. 

Jump if not equal/Jump if not zero. 

Jump if above/Jump if not below or equal. 
Jump if above or equal/Jump if not below. 
Jump if below/Jump if not above or equal. 
Jump if below or equal/Jump if not above. 
Jump if greater/Jump if not less or equal. 

Jump if greater or equal/Jump if not less. 

Jump if less/Jump if not greater or equal. 
Jump if less or equal/Jump if not greater. 

Jump if carry. 

Jump if not carry. 

Jump if overflow. 

Jump if not overflow. 

Jump if sign (negative). 

Jump if not sign (non-negative). 


1. Processor support of CRC32 is enumerated by CPUID.01:ECX[SSE4.2] = 1 
2. Processor support of POPCNT is enumerated by CPUID.01:ECX[POPCNT] = 1 
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JPO/JNP 
JPE/JP 
JCXZ/JECXZ 
LOOP 
LOOPZ/LOOPE 


LOOPNZ/LOOPNE 


CALL 
RET 
IRET 
INT 
INTO 
BOUND 
ENTER 
LEAVE 


Jump if parity odd/Jump if not parity. 

Jump if parity even/Jump if parity. 

Jump register CX zero/Jump register ECX zero. 
Loop with ECX counter. 

Loop with ECX and zero/Loop with ECX and equal. 
Loop with ECX and not zero/Loop with ECX and not equal. 
Call procedure. 

Return. 

Return from interrupt. 

Software interrupt. 

Interrupt on overflow. 

Detect value out of range. 

High-level procedure entry. 

High-level procedure exit. 


5.1.8 String Instructions 


The string instructions operate on strings of bytes, allowing them to be moved to and from memory. 


MOVS/MOVSB 
MOVS/MOVSW 
MOVS/MOVSD 
CMPS/CMPSB 
CMPS/CMPSW 
CMPS/CMPSD 
SCAS/SCASB 
SCAS/SCASW 
SCAS/SCASD 
LODS/LODSB 
LODS/LODSW 
LODS/LODSD 
STOS/STOSB 
STOS/STOSW 
STOS/STOSD 
REP 
REPE/REPZ 
REPNE/REPNZ 


Move string/Move byte string. 

Move string/Move word string. 

Move string/Move doubleword string. 
Compare string/Compare byte string. 
Compare string/Compare word string. 
Compare string/Compare doubleword string. 
Scan string/Scan byte string. 

Scan string/Scan word string. 

Scan string/Scan doubleword string. 

Load string/Load byte string. 

Load string/Load word string. 

Load string/Load doubleword string. 

Store string/Store byte string. 

Store string/Store word string. 

Store string/Store doubleword string. 
Repeat while ECX not zero. 

Repeat while equal/Repeat while zero. 
Repeat while not equal/Repeat while not zero. 


5.1.9 I/O Instructions 


These instructions move data between the processor’s I/O ports and a register or memory. 


IN 

OUT 
INS/INSB 
INS/INSW 
INS/INSD 
OUTS/OUTSB 
OUTS/OUTSW 
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Read from a port. 

Write to a port. 

Input string from port/Input byte string from port. 

Input string from port/Input word string from port. 

Input string from port/Input doubleword string from port. 
Output string to port/Output byte string to port. 

Output string to port/Output word string to port. 


INSTRUCTION SET SUMMARY 


OUTS/OUTSD Output string to port/Output doubleword string to port. 


5.1.10 Enter and Leave Instructions 


These instructions provide machine-language support for procedure calls in block-structured languages. 
ENTER High-level procedure entry. 
LEAVE High-level procedure exit. 


5.1.11 Flag Control (EFLAG) Instructions 


The flag control instructions operate on the flags in the EFLAGS register. 


STC Set carry flag. 

CLC Clear the carry flag. 

CMC Complement the carry flag. 
CLD Clear the direction flag. 
STD Set direction flag. 

LAHF Load flags into AH register. 
SAHF Store AH register into flags. 
PUSHF/PUSHFD Push EFLAGS onto stack. 
POPF/POPFD Pop EFLAGS from stack. 
STI Set interrupt flag. 

CLI Clear the interrupt flag. 


5.1.12 Segment Register Instructions 


The segment register instructions allow far pointers (segment addresses) to be loaded into the segment registers. 
LDS Load far pointer using DS. 


LES Load far pointer using ES. 
LFS Load far pointer using FS. 
LGS Load far pointer using GS. 
LSS Load far pointer using SS. 


5.1.13. Miscellaneous Instructions 


The miscellaneous instructions provide such functions as loading an effective address, executing a “no-operation,” 
and retrieving processor identification information. 


LEA Load effective address. 

NOP No operation. 

UD Undefined instruction. 

XLAT/XLATB Table lookup translation. 

CPUID Processor identification. 

MOVBE! Move data after swapping data bytes. 
PREFETCHW Prefetch data into cache in anticipation of write. 
PREFETCHWT1 Prefetch hint T1 with intent to write. 


1. Processor support of MOVBE is enumerated by CPUID.01:ECX.MOVBE[bit 22] = 1. 
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CLFLUSH Flushes and invalidates a memory operand and its associated cache line from all levels of 
the processor’s cache hierarchy. 
CLFLUSHOPT Flushes and invalidates a memory operand and its associated cache line from all levels of 


the processor’s cache hierarchy with optimized memory system throughput. 


5.1.14 User Mode Extended Sate Save/Restore Instructions 


XSAVE Save processor extended states to memory. 

XSAVEC Save processor extended states with compaction to memory. 
XSAVEOPT Save processor extended states to memory, optimized. 
XRSTOR Restore processor extended states from memory. 

XGETBV Reads the state of an extended control register. 


5.1.15 Random Number Generator Instructions 
RDRAND Retrieves a random number generated from hardware. 
RDSEED Retrieves a random number generated from hardware. 


5.1.16 BMI1, BMI2 


ANDN Bitwise AND of first source with inverted 2nd source operands. 
BEXTR Contiguous bitwise extract. 

BLSI Extract lowest set bit. 

BLSMSK Set all lower bits below first set bit to 1. 

BLSR Reset lowest set bit. 

BZHI Zero high bits starting from specified bit position. 
LZCNT Count the number leading zero bits. 

MULX Unsigned multiply without affecting arithmetic flags. 
PDEP Parallel deposit of bits using a mask. 

PEXT Parallel extraction of bits using a mask. 

RORX Rotate right without affecting arithmetic flags. 
SARX Shift arithmetic right. 

SHLX Shift logic left. 

SHRX Shift logic right. 

TZCNT Count the number trailing zero bits. 


5.1.16.1 Detection of VEX-encoded GPR Instructions, LZCNT and TZCNT, PREFETCHW 
VEX-encoded general-purpose instructions do not operate on any vector registers. 


There are separate feature flags for the following subsets of instructions that operate on general purpose registers, 
and the detection requirements for hardware support are: 


CPUID.(EAX=07H, ECX=0H):EBX.BMI1[bit 3]: if 1 indicates the processor supports the first group of advanced bit 
manipulation extensions (ANDN, BEXTR, BLSI, BLSMSK, BLSR, TZCNT); 


CPUID.(EAX=07H, ECX=0H):EBX.BMI2[bit 8]: if 1 indicates the processor supports the second group of advanced 
bit manipulation extensions (BZHI, MULX, PDEP, PEXT, RORX, SARX, SHLX, SHRX); 


CPUID.EAX=80000001H:ECX.LZCNT[bit 5]: if 1 indicates the processor supports the LZCNT instruction. 


CPUID.EAX=80000001H:ECX.PREFTEHCHW/[bit 8]: if 1 indicates the processor supports the PREFTEHCHW instruc- 
tion. CPUID.(EAX=07H, ECX=0H):ECX.PREFTEHCHWT1[bit 0]: if 1 indicates the processor supports the 
PREFTEHCHWT1 instruction. 
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ows X87 FPU INSTRUCTIONS 


The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, 
integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, 
“Programming with the x87 FPU.” 


These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instruc- 
tions. The sections that follow introduce each subgroup. 


5.2.1 x87 FPU Data Transfer Instructions 


The data transfer instructions move floating-point, integer, and BCD values between memory and the x87 FPU 
registers. They also perform conditional move operations on floating-point operands. 


FLD Load floating-point value. 

FST Store floating-point value. 

FSTP Store floating-point value and pop. 

FILD Load integer. 

FIST Store integer. 

FISTP! Store integer and pop. 

FBLD Load BCD. 

FBSTP Store BCD and pop. 

FXCH Exchange registers. 

FCMOVE Floating-point conditional move if equal. 
FCMOVNE Floating-point conditional move if not equal. 
FCMOVB Floating-point conditional move if below. 
FCMOVBE Floating-point conditional move if below or equal. 
FCMOVNB Floating-point conditional move if not below. 
FCMOVNBE Floating-point conditional move if not below or equal. 
FCMOVU Floating-point conditional move if unordered. 
FCMOVNU Floating-point conditional move if not unordered. 


5.2.2 x87 FPU Basic Arithmetic Instructions 


The basic arithmetic instructions perform basic arithmetic operations on floating-point and integer operands. 
FADD Add floating-point 


FADDP Add floating-point and pop 
FIADD Add integer 

FSUB Subtract floating-point 

FSUBP Subtract floating-point and pop 
FISUB Subtract integer 

FSUBR Subtract floating-point reverse 
FSUBRP Subtract floating-point reverse and pop 
FISUBR Subtract integer reverse 

FMUL Multiply floating-point 

FMULP Multiply floating-point and pop 
FIMUL Multiply integer 

FDIV Divide floating-point 


1. SSE3 provides an instruction FISTTP for integer conversion. 
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FDIVP Divide floating-point and pop 
FIDIV Divide integer 

FDIVR Divide floating-point reverse 
FDIVRP Divide floating-point reverse and pop 
FIDIVR Divide integer reverse 

FPREM Partial remainder 

FPREM1 IEEE Partial remainder 

FABS Absolute value 

FCHS Change sign 

FRNDINT Round to integer 

FSCALE Scale by power of two 

FSQRT Square root 

FXTRACT Extract exponent and significand 


5.2.3 x87 FPU Comparison Instructions 


The compare instructions examine or compare floating-point or integer operands. 


FCOM Compare floating-point. 

FCOMP Compare floating-point and pop. 

FCOMPP Compare floating-point and pop twice. 

FUCOM Unordered compare floating-point. 

FUCOMP Unordered compare floating-point and pop. 
FUCOMPP Unordered compare floating-point and pop twice. 
FICOM Compare integer. 

FICOMP Compare integer and pop. 

FCOMI Compare floating-point and set EFLAGS. 

FUCOMI Unordered compare floating-point and set EFLAGS. 
FCOMIP Compare floating-point, set EFLAGS, and pop. 
FUCOMIP Unordered compare floating-point, set EFLAGS, and pop. 
FTST Test floating-point (compare with 0.0). 

FXAM Examine floating-point. 


5.2.4 x87 FPU Transcendental Instructions 


The transcendental instructions perform basic trigonometric and logarithmic operations on floating-point operands. 
FSIN Sine 


FCOS Cosine 

FSINCOS Sine and cosine 
FPTAN Partial tangent 
FPATAN Partial arctangent 
F2XM1 2*—1 

FYL2X y*logox 

FYL2XP1 y*logo(x+1) 


5.2.5 x87 FPU Load Constants Instructions 


The load constants instructions load common constants, such as 7, into the x87 floating-point registers. 
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FLD1 Load +1.0 
FLDZ Load +0.0 
FLDPI Load x 
FLDL2E Load logze 
FLDLN2 Load log,.2 
FLDL2T Load log>10 
FLDLG2 Load log492 


5.2.6 x87 FPU Control Instructions 


The x87 FPU control instructions operate on the x87 FPU register stack and save and restore the x87 FPU state. 


FINCSTP Increment FPU register stack pointer. 

FDECSTP Decrement FPU register stack pointer. 

FFREE Free floating-point register. 

FINIT Initialize FPU after checking error conditions. 

FNINIT Initialize FPU without checking error conditions. 

FCLEX Clear floating-point exception flags after checking for error conditions. 
FNCLEX Clear floating-point exception flags without checking for error conditions. 
FSTCW Store FPU control word after checking error conditions. 

FNSTCW Store FPU control word without checking error conditions. 

FLDCW Load FPU control word. 

FSTENV Store FPU environment after checking error conditions. 

FNSTENV Store FPU environment without checking error conditions. 

FLDENV Load FPU environment. 

FSAVE Save FPU state after checking error conditions. 

FNSAVE Save FPU state without checking error conditions. 

FRSTOR Restore FPU state. 

FSTSW Store FPU status word after checking error conditions. 

FNSTSW Store FPU status word without checking error conditions. 
WAIT/FWAIT Wait for FPU. 

FNOP FPU no operation. 


5.3 X87 FPU AND SIMD STATE MANAGEMENT INSTRUCTIONS 


Two state management instructions were introduced into the IA-32 architecture with the Pentium II processor 
family: 

FXSAVE Save x87 FPU and SIMD state. 

FXRSTOR Restore x87 FPU and SIMD state. 

Initially, these instructions operated only on the x87 FPU (and MMX) registers to perform a fast save and restore, 
respectively, of the x87 FPU and MMxX state. With the introduction of SSE extensions in the Pentium III processor 


family, these instructions were expanded to also save and restore the state of the XMM and MXCSR registers. Intel 
64 architecture also supports these instructions. 


See Section 10.5, “FXSAVE and FXRSTOR Instructions,” for more detail. 


5.4 MMX™ INSTRUCTIONS 


Four extensions have been introduced into the IA-32 architecture to permit IA-32 processors to perform single- 
instruction multiple-data (SIMD) operations. These extensions include the MMX technology, SSE extensions, SSE2 
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extensions, and SSE3 extensions. For a discussion that puts SIMD instructions in their historical context, see 
Section 2.2.7, “SIMD Instructions.” 


MMX instructions operate on packed byte, word, doubleword, or quadword integer operands contained in memory, 
in MMX registers, and/or in general-purpose registers. For more detail on these instructions, see Chapter 9, 
“Programming with Intel® MMX™ Technology.” 


MM X instructions can only be executed on Intel 64 and IA-32 processors that support the MMX technology. Support 
for these instructions can be detected with the CPUID instruction. See the description of the CPUID instruction in 
Chapter 3, “Instruction Set Reference, A-L,” of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 2A. 


MMX instructions are divided into the following subgroups: data transfer, conversion, packed arithmetic, compar- 
ison, logical, shift and rotate, and state management instructions. The sections that follow introduce each 
subgroup. 


5.4.1 MMxX Data Transfer Instructions 


The data transfer instructions move doubleword and quadword operands between MMX registers and between MMX 
registers and memory. 


MOVD Move doubleword. 
MOVQ Move quadword. 


5.4.2 MMxX Conversion Instructions 


The conversion instructions pack and unpack bytes, words, and doublewords 


PACKSSWB Pack words into bytes with signed saturation. 
PACKSSDW Pack doublewords into words with signed saturation. 
PACKUSWB Pack words into bytes with unsigned saturation. 
PUNPCKHBW Unpack high-order bytes. 

PUNPCKHWD Unpack high-order words. 

PUNPCKHDQ Unpack high-order doublewords. 

PUNPCKLBW Unpack low-order bytes. 

PUNPCKLWD Unpack low-order words. 

PUNPCKLDQ Unpack low-order doublewords. 


5.4.3 MMxX Packed Arithmetic Instructions 


The packed arithmetic instructions perform packed integer arithmetic on packed byte, word, and doubleword inte- 
gers. 


PADDB Add packed byte integers. 

PADDW Add packed word integers. 

PADDD Add packed doubleword integers. 

PADDSB Add packed signed byte integers with signed saturation. 
PADDSW Add packed signed word integers with signed saturation. 
PADDUSB Add packed unsigned byte integers with unsigned saturation. 
PADDUSW Add packed unsigned word integers with unsigned saturation. 
PSUBB Subtract packed byte integers. 

PSUBW Subtract packed word integers. 

PSUBD Subtract packed doubleword integers. 

PSUBSB Subtract packed signed byte integers with signed saturation. 
PSUBSW Subtract packed signed word integers with signed saturation. 
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PSUBUSB Subtract packed unsigned byte integers with unsigned saturation. 
PSUBUSW Subtract packed unsigned word integers with unsigned saturation. 
PMULHW Multiply packed signed word integers and store high result. 
PMULLW Multiply packed signed word integers and store low result. 
PMADDWD Multiply and add packed word integers. 


5.4.4 MMX Comparison Instructions 


The compare instructions compare packed bytes, words, or doublewords. 


PCMPEQB Compare packed bytes for equal. 

PCMPEQW Compare packed words for equal. 

PCMPEQD Compare packed doublewords for equal. 

PCMPGTB Compare packed signed byte integers for greater than. 
PCMPGTW Compare packed signed word integers for greater than. 
PCMPGTD Compare packed signed doubleword integers for greater than. 


5.4.5 MMxX Logical Instructions 
The logical instructions perform AND, AND NOT, OR, and XOR operations on quadword operands. 


PAND Bitwise logical AND. 

PANDN Bitwise logical AND NOT. 
POR Bitwise logical OR. 

PXOR Bitwise logical exclusive OR. 


5.4.6 MMxX Shift and Rotate Instructions 


The shift and rotate instructions shift and rotate packed bytes, words, or doublewords, or quadwords in 64-bit 
operands. 


PSLLW Shift packed words left logical. 

PSLLD Shift packed doublewords left logical. 
PSLLQ Shift packed quadword left logical. 

PSRLW Shift packed words right logical. 

PSRLD Shift packed doublewords right logical. 
PSRLQ Shift packed quadword right logical. 
PSRAW Shift packed words right arithmetic. 
PSRAD Shift packed doublewords right arithmetic. 


5.4.7 MMX State Management Instructions 


The EMMS instruction clears the MMX state from the MMX registers. 
EMMS Empty MMX state. 


oe) SSE INSTRUCTIONS 


SSE instructions represent an extension of the SIMD execution model introduced with the MMX technology. For 
more detail on these instructions, see Chapter 10, “Programming with Intel® Streaming SIMD Extensions (Intel® 
SSE).” 
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SSE instructions can only be executed on Intel 64 and IA-32 processors that support SSE extensions. Support for 
these instructions can be detected with the CPUID instruction. See the description of the CPUID instruction in 
Chapter 3, “Instruction Set Reference, A-L,” of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 2A. 


SSE instructions are divided into four subgroups (note that the first subgroup has subordinate subgroups of its 
own): 


¢ SIMD single-precision floating-point instructions that operate on the XMM registers. 
° MXCSR state management instructions. 

°® 64-bit SIMD integer instructions that operate on the MMxX registers. 

® Cacheability control, prefetch, and instruction ordering instructions. 

The following sections provide an overview of these groups. 


5.5.1 SSE SIMD Single-Precision Floating-Point Instructions 


These instructions operate on packed and scalar single-precision floating-point values located in XMM registers 
and/or memory. This subgroup is further divided into the following subordinate subgroups: data transfer, packed 
arithmetic, comparison, logical, shuffle and unpack, and conversion instructions. 


5.5.1.1 SSE Data Transfer Instructions 


SSE data transfer instructions move packed and scalar single-precision floating-point operands between XMM 
registers and between XMM registers and memory. 


MOVAPS Move four aligned packed single-precision floating-point values between XMM registers or 
between and XMM register and memory. 

MOVUPS Move four unaligned packed single-precision floating-point values between XMM registers 
or between and XMM register and memory. 

MOVHPS Move two packed single-precision floating-point values to an from the high quadword of an 
XMM register and memory. 

MOVHLPS Move two packed single-precision floating-point values from the high quadword of an XMM 
register to the low quadword of another XMM register. 

MOVLPS Move two packed single-precision floating-point values to an from the low quadword of an 
XMM register and memory. 

MOVLHPS Move two packed single-precision floating-point values from the low quadword of an XMM 
register to the high quadword of another XMM register. 

MOVMSKPS Extract sign mask from four packed single-precision floating-point values. 

MOVSS Move scalar single-precision floating-point value between XMM registers or between an 


XMM register and memory. 


5.5.1.2 SSE Packed Arithmetic Instructions 


SSE packed arithmetic instructions perform packed and scalar arithmetic operations on packed and scalar single- 
precision floating-point operands. 


ADDPS Add packed single-precision floating-point values. 
ADDSS Add scalar single-precision floating-point values. 
SUBPS Subtract packed single-precision floating-point values. 
SUBSS Subtract scalar single-precision floating-point values. 
MULPS Multiply packed single-precision floating-point values. 
MULSS Multiply scalar single-precision floating-point values. 
DIVPS Divide packed single-precision floating-point values. 
DIVSS Divide scalar single-precision floating-point values. 
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RCPPS Compute reciprocals of packed single-precision floating-point values. 

RCPSS Compute reciprocal of scalar single-precision floating-point values. 

SQRTPS Compute square roots of packed single-precision floating-point values. 

SQRTSS Compute square root of scalar single-precision floating-point values. 

RSQRTPS Compute reciprocals of square roots of packed single-precision floating-point values. 
RSQRTSS Compute reciprocal of square root of scalar single-precision floating-point values. 
MAXPS Return maximum packed single-precision floating-point values. 

MAXSS Return maximum scalar single-precision floating-point values. 

MINPS Return minimum packed single-precision floating-point values. 

MINSS Return minimum scalar single-precision floating-point values. 


5.9.1.3 SSE Comparison Instructions 


SSE compare instructions compare packed and scalar single-precision floating-point operands. 


CMPPS Compare packed single-precision floating-point values. 

CMPSS Compare scalar single-precision floating-point values. 

COMISS Perform ordered comparison of scalar single-precision floating-point values and set flags in 
EFLAGS register. 

UCOMISS Perform unordered comparison of scalar single-precision floating-point values and set flags 


in EFLAGS register. 


5.5.1.4 SSE Logical Instructions 


SSE logical instructions perform bitwise AND, AND NOT, OR, and XOR operations on packed single-precision 
floating-point operands. 


ANDPS Perform bitwise logical AND of packed single-precision floating-point values. 
ANDNPS Perform bitwise logical AND NOT of packed single-precision floating-point values. 
ORPS Perform bitwise logical OR of packed single-precision floating-point values. 
XORPS Perform bitwise logical XOR of packed single-precision floating-point values. 


oe eal Pee SSE Shuffle and Unpack Instructions 


SSE shuffle and unpack instructions shuffle or interleave single-precision floating-point values in packed single- 
precision floating-point operands. 


SHUFPS Shuffles values in packed single-precision floating-point operands. 

UNPCKHPS Unpacks and interleaves the two high-order values from two single-precision floating-point 
operands. 

UNPCKLPS Unpacks and interleaves the two low-order values from two single-precision floating-point 
operands. 


5.5.1.6 SSE Conversion Instructions 


SSE conversion instructions convert packed and individual doubleword integers into packed and scalar single- 
precision floating-point values and vice versa. 


CVTPI2PS Convert packed doubleword integers to packed single-precision floating-point values. 

CVTSI2SS Convert doubleword integer to scalar single-precision floating-point value. 

CVTPS2PI Convert packed single-precision floating-point values to packed doubleword integers. 

CVTTPS2PI Convert with truncation packed single-precision floating-point values to packed double- 
word integers. 

CVTSS2SI Convert a scalar single-precision floating-point value to a doubleword integer. 
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CVTTSS2SI Convert with truncation a scalar single-precision floating-point value to a scalar double- 
word integer. 


5.5.2 SSE MXCSR State Management Instructions 

MXCSR state management instructions allow saving and restoring the state of the MXCSR control and status 
register. 

LDMXCSR Load MXCSR register. 

STMXCSR Save MXCSR register state. 


5.5.3 SSE 64-Bit SIMD Integer Instructions 


These SSE 64-bit SIMD integer instructions perform additional operations on packed bytes, words, or doublewords 
contained in MMX registers. They represent enhancements to the MMX instruction set described in Section 5.4, 
“MMX™ Instructions.” 


PAVGB Compute average of packed unsigned byte integers. 
PAVGW Compute average of packed unsigned word integers. 
PEXTRW Extract word. 

PINSRW Insert word. 

PMAXUB Maximum of packed unsigned byte integers. 
PMAXSW Maximum of packed signed word integers. 
PMINUB Minimum of packed unsigned byte integers. 
PMINSW Minimum of packed signed word integers. 
PMOVMSKB Move byte mask. 

PMULHUW Multiply packed unsigned integers and store high result. 
PSADBW Compute sum of absolute differences. 

PSHUFW Shuffle packed integer word in MMX register. 


5.5.4 SSE Cacheability Control, Prefetch, and Instruction Ordering Instructions 


The cacheability control instructions provide control over the caching of non-temporal data when storing data from 
the MMX and XMM registers to memory. The PREFETCHA allows data to be prefetched to a selected cache level. The 
SFENCE instruction controls instruction ordering on store operations. 


MASKMOVQ Non-temporal store of selected bytes from an MMX register into memory. 

MOVNTQ Non-temporal store of quadword from an MMX register into memory. 

MOVNTPS Non-temporal store of four packed single-precision floating-point values from an XMM 
register into memory. 

PREFETCHA Load 32 or more of bytes from memory to a selected level of the processor’s cache hier- 
archy 

SFENCE Serializes store operations. 


5.6 SSE2 INSTRUCTIONS 


SSE2 extensions represent an extension of the SIMD execution model introduced with MMX technology and the 
SSE extensions. SSE2 instructions operate on packed double-precision floating-point operands and on packed 
byte, word, doubleword, and quadword operands located in the XMM registers. For more detail on these instruc- 
tions, see Chapter 11, “Programming with Intel® Streaming SIMD Extensions 2 (Intel® SSE2).” 


SSE2 instructions can only be executed on Intel 64 and IA-32 processors that support the SSE2 extensions. 
Support for these instructions can be detected with the CPUID instruction. See the description of the CPUID instruc- 
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tion in Chapter 3, “Instruction Set Reference, A-L,” of the Inte/® 64 and IA-32 Architectures Software Developer’s 
Manual, Volume 2A. 


These instructions are divided into four subgroups (note that the first subgroup is further divided into subordinate 
subgroups): 


¢ Packed and scalar double-precision floating-point instructions. 
¢ Packed single-precision floating-point conversion instructions. 
¢ 128-bit SIMD integer instructions. 

* Cacheability-control and instruction ordering instructions. 
The following sections give an overview of each subgroup. 


5.6.1 SSE2 Packed and Scalar Double-Precision Floating-Point Instructions 


SSE2 packed and scalar double-precision floating-point instructions are divided into the following subordinate 
subgroups: data movement, arithmetic, comparison, conversion, logical, and shuffle operations on double-preci- 
sion floating-point operands. These are introduced in the sections that follow. 


5.6.1.1 SSE2 Data Movement Instructions 


SSE2 data movement instructions move double-precision floating-point data between XMM registers and between 
XMM registers and memory. 


MOVAPD Move two aligned packed double-precision floating-point values between XMM registers or 
between and XMM register and memory. 

MOVUPD Move two unaligned packed double-precision floating-point values between XMM registers 
or between and XMM register and memory. 

MOVHPD Move high packed double-precision floating-point value to an from the high quadword of an 
XMM register and memory. 

MOVLPD Move low packed single-precision floating-point value to an from the low quadword of an 
XMM register and memory. 

MOVMSKPD Extract sign mask from two packed double-precision floating-point values. 

MOVSD Move scalar double-precision floating-point value between XMM registers or between an 


XMM register and memory. 


5.6.1.2 SSE2 Packed Arithmetic Instructions 


The arithmetic instructions perform addition, subtraction, multiply, divide, square root, and maximum/minimum 
operations on packed and scalar double-precision floating-point operands. 


ADDPD Add packed double-precision floating-point values. 

ADDSD Add scalar double precision floating-point values. 

SUBPD Subtract packed double-precision floating-point values. 

SUBSD Subtract scalar double-precision floating-point values. 

MULPD Multiply packed double-precision floating-point values. 

MULSD Multiply scalar double-precision floating-point values. 

DIVPD Divide packed double-precision floating-point values. 

DIVSD Divide scalar double-precision floating-point values. 

SQRTPD Compute packed square roots of packed double-precision floating-point values. 
SQRTSD Compute scalar square root of scalar double-precision floating-point values. 
MAXPD Return maximum packed double-precision floating-point values. 

MAXSD Return maximum scalar double-precision floating-point values. 

MINPD Return minimum packed double-precision floating-point values. 
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MINSD Return minimum scalar double-precision floating-point values. 


5.6.1.3 SSE2 Logical Instructions 


SSE2 logical instructions perform AND, AND NOT, OR, and XOR operations on packed double-precision floating- 
point values. 


ANDPD Perform bitwise logical AND of packed double-precision floating-point values. 
ANDNPD Perform bitwise logical AND NOT of packed double-precision floating-point values. 
ORPD Perform bitwise logical OR of packed double-precision floating-point values. 
XORPD Perform bitwise logical XOR of packed double-precision floating-point values. 


5.6.1.4 SSE2 Compare Instructions 


SSE2 compare instructions compare packed and scalar double-precision floating-point values and return the 
results of the comparison either to the destination operand or to the EFLAGS register. 


CMPPD Compare packed double-precision floating-point values. 

CMPSD Compare scalar double-precision floating-point values. 

COMISD Perform ordered comparison of scalar double-precision floating-point values and set flags 
in EFLAGS register. 

UCOMISD Perform unordered comparison of scalar double-precision floating-point values and set 


flags in EFLAGS register. 


5.6.1.5 SSE2 Shuffle and Unpack Instructions 


SSE2 shuffle and unpack instructions shuffle or interleave double-precision floating-point values in packed double- 
precision floating-point operands. 


SHUFPD Shuffles values in packed double-precision floating-point operands. 

UNPCKHPD Unpacks and interleaves the high values from two packed double-precision floating-point 
operands. 

UNPCKLPD Unpacks and interleaves the low values from two packed double-precision floating-point 
operands. 


5.6.1.6 SSE2 Conversion Instructions 


SSE2 conversion instructions convert packed and individual doubleword integers into packed and scalar double- 
precision floating-point values and vice versa. They also convert between packed and scalar single-precision and 
double-precision floating-point values. 


CVTPD2PI Convert packed double-precision floating-point values to packed doubleword integers. 

CVTTPD2PI Convert with truncation packed double-precision floating-point values to packed double- 
word integers. 

CVTPI2PD Convert packed doubleword integers to packed double-precision floating-point values. 

CVTPD2DQ Convert packed double-precision floating-point values to packed doubleword integers. 

CVTTPD2DQ Convert with truncation packed double-precision floating-point values to packed double- 
word integers. 

CVTDQ2PD Convert packed doubleword integers to packed double-precision floating-point values. 

CVTPS2PD Convert packed single-precision floating-point values to packed double-precision floating- 
point values. 

CVTPD2PS Convert packed double-precision floating-point values to packed single-precision floating- 
point values. 

CVTSS2SD Convert scalar single-precision floating-point values to scalar double-precision floating- 
point values. 
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CVTSD2SS Convert scalar double-precision floating-point values to scalar single-precision floating- 
point values. 

CVTSD2SI Convert scalar double-precision floating-point values to a doubleword integer. 

CVTTSD2SI Convert with truncation scalar double-precision floating-point values to scalar doubleword 
integers. 

CVTSI2SD Convert doubleword integer to scalar double-precision floating-point value. 


5.6.2 SSE2 Packed Single-Precision Floating-Point Instructions 


SSE2 packed single-precision floating-point instructions perform conversion operations on single-precision 
floating-point and integer operands. These instructions represent enhancements to the SSE single-precision 
floating-point instructions. 


CVTDQ2PS Convert packed doubleword integers to packed single-precision floating-point values. 
CVTPS2DQ Convert packed single-precision floating-point values to packed doubleword integers. 
CVTTPS2DQ Convert with truncation packed single-precision floating-point values to packed double- 


word integers. 


5.6.3 SSE2 128-Bit SIMD Integer Instructions 


SSE2 SIMD integer instructions perform additional operations on packed words, doublewords, and quadwords 
contained in XMM and MMxX registers. 


MOVDQA Move aligned double quadword. 

MOVDQU Move unaligned double quadword. 

MOVQ2DQ Move quadword integer from MMX to XMM registers. 
MOVDQ2Q Move quadword integer from XMM to MMX registers. 
PMULUDQ Multiply packed unsigned doubleword integers. 
PADDQ Add packed quadword integers. 

PSUBQ Subtract packed quadword integers. 

PSHUFLW Shuffle packed low words. 

PSHUFHW Shuffle packed high words. 

PSHUFD Shuffle packed doublewords. 

PSLLDQ Shift double quadword left logical. 

PSRLDQ Shift double quadword right logical. 

PUNPCKHQDQ Unpack high quadwords. 

PUNPCKLQDQ Unpack low quadwords. 


5.6.4 SSE2 Cacheability Control and Ordering Instructions 


SSE2 cacheability control instructions provide additional operations for caching of non-temporal data when storing 
data from XMM registers to memory. LFENCE and MFENCE provide additional control of instruction ordering on 
store operations. 


CLFLUSH See Section 5.1.13. 

LFENCE Serializes load operations. 

MFENCE Serializes load and store operations. 

PAUSE Improves the performance of “spin-wait loops”. 

MASKMOVDQU Non-temporal store of selected bytes from an XMM register into memory. 

MOVNTPD Non-temporal store of two packed double-precision floating-point values from an XMM 
register into memory. 

MOVNTDQ Non-temporal store of double quadword from an XMM register into memory. 
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MOVNTI Non-temporal store of a doubleword from a general-purpose register into memory. 


5.7 SSE3 INSTRUCTIONS 


The SSE3 extensions offers 13 instructions that accelerate performance of Streaming SIMD Extensions technology, 
Streaming SIMD Extensions 2 technology, and x87-FP math capabilities. These instructions can be grouped into the 
following categories: 


® One x87FPU instruction used in integer conversion. 

* One SIMD integer instruction that addresses unaligned data loads. 
* Two SIMD floating-point packed ADD/SUB instructions. 

¢ Four SIMD floating-point horizontal ADD/SUB instructions. 

¢ Three SIMD floating-point LOAD/MOVE/DUPLICATE instructions. 

* Two thread synchronization instructions. 


SSE3 instructions can only be executed on Intel 64 and IA-32 processors that support SSE3 extensions. Support 
for these instructions can be detected with the CPUID instruction. See the description of the CPUID instruction in 
Chapter 3, “Instruction Set Reference, A-L,” of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 2A. 


The sections that follow describe each subgroup. 


5.7.1 SSE3 x87-FP Integer Conversion Instruction 


FISTTP Behaves like the FISTP instruction but uses truncation, irrespective of the rounding mode 
specified in the floating-point control word (FCW). 


5.7.2 SSE3 Specialized 1 28-bit Unaligned Data Load Instruction 
LDDQU Special 128-bit unaligned load designed to avoid cache line splits. 


5.7.3 SSE3 SIMD Floating-Point Packed ADD/SUB Instructions 


ADDSUBPS Performs single-precision addition on the second and fourth pairs of 32-bit data elements 
within the operands; single-precision subtraction on the first and third pairs. 
ADDSUBPD Performs double-precision addition on the second pair of quadwords, and double-precision 


subtraction on the first pair. 


5.7.4 SSE3 SIMD Floating-Point Horizontal ADD/SUB Instructions 


HADDPS Performs a single-precision addition on contiguous data elements. The first data element of 
the result is obtained by adding the first and second elements of the first operand; the 
second element by adding the third and fourth elements of the first operand; the third by 
adding the first and second elements of the second operand; and the fourth by adding the 
third and fourth elements of the second operand. 


HSUBPS Performs a single-precision subtraction on contiguous data elements. The first data 
element of the result is obtained by subtracting the second element of the first operand 
from the first element of the first operand; the second element by subtracting the fourth 
element of the first operand from the third element of the first operand; the third by 
subtracting the second element of the second operand from the first element of the second 
operand; and the fourth by subtracting the fourth element of the second operand from the 
third element of the second operand. 
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HADDPD Performs a double-precision addition on contiguous data elements. The first data element 
of the result is obtained by adding the first and second elements of the first operand; the 
second element by adding the first and second elements of the second operand. 


HSUBPD Performs a double-precision subtraction on contiguous data elements. The first data 
element of the result is obtained by subtracting the second element of the first operand 
from the first element of the first operand; the second element by subtracting the second 
element of the second operand from the first element of the second operand. 


5.75 SSE3 SIMD Floating-Point LOAD/MOVE/DUPLICATE Instructions 


MOVSHDUP Loads/moves 128 bits; duplicating the second and fourth 32-bit data elements. 

MOVSLDUP Loads/moves 128 bits; duplicating the first and third 32-bit data elements. 

MOVDDUP Loads/moves 64 bits (bits[63:0] if the source is a register) and returns the same 64 bits in 
both the lower and upper halves of the 128-bit result register; duplicates the 64 bits from 
the source. 


5.7.6 SSE3 Agent Synchronization Instructions 
MONITOR Sets up an address range used to monitor write-back stores. 


MWAIT Enables a logical processor to enter into an optimized state while waiting for a write-back 
store to the address range set up by the MONITOR instruction. 


5.8 SUPPLEMENTAL STREAMING SIMD EXTENSIONS 3 (SSSE3) INSTRUCTIONS 


SSSE3 provide 32 instructions (represented by 14 mnemonics) to accelerate computations on packed integers. 
These include: 


¢ Twelve instructions that perform horizontal addition or subtraction operations. 

¢ Six instructions that evaluate absolute values. 

* Two instructions that perform multiply and add operations and speed up the evaluation of dot products. 

° Two instructions that accelerate packed-integer multiply operations and produce integer values with scaling. 
¢ Two instructions that perform a byte-wise, in-place shuffle according to the second shuffle control operand. 


¢ Six instructions that negate packed integers in the destination operand if the signs of the corresponding 
element in the source operand is less than zero. 


* Two instructions that align data from the composite of two operands. 


SSSE3 instructions can only be executed on Intel 64 and IA-32 processors that support SSSE3 extensions. Support 
for these instructions can be detected with the CPUID instruction. See the description of the CPUID instruction in 
Chapter 3, “Instruction Set Reference, A-L,” of the Inte/® 64 and IA-32 Architectures Software Developer’s 
Manual, Volume 2A. 


The sections that follow describe each subgroup. 


5.8.1 Horizontal Addition/Subtraction 


PHADDW Adds two adjacent, signed 16-bit integers horizontally from the source and destination 
operands and packs the signed 16-bit results to the destination operand. 

PHADDSW Adds two adjacent, signed 16-bit integers horizontally from the source and destination 
operands and packs the signed, saturated 16-bit results to the destination operand. 

PHADDD Adds two adjacent, signed 32-bit integers horizontally from the source and destination 
operands and packs the signed 32-bit results to the destination operand. 

PHSUBW Performs horizontal subtraction on each adjacent pair of 16-bit signed integers by 


subtracting the most significant word from the least significant word of each pair in the 
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source and destination operands. The signed 16-bit results are packed and written to the 
destination operand. 


PHSUBSW Performs horizontal subtraction on each adjacent pair of 16-bit signed integers by 
subtracting the most significant word from the least significant word of each pair in the 
source and destination operands. The signed, saturated 16-bit results are packed and 
written to the destination operand. 

PHSUBD Performs horizontal subtraction on each adjacent pair of 32-bit signed integers by 
subtracting the most significant doubleword from the least significant double word of each 
pair in the source and destination operands. The signed 32-bit results are packed and 
written to the destination operand. 


5.8.2 Packed Absolute Values 


PABSB Computes the absolute value of each signed byte data element. 
PABSW Computes the absolute value of each signed 16-bit data element. 
PABSD Computes the absolute value of each signed 32-bit data element. 


5.8.3 Multiply and Add Packed Signed and Unsigned Bytes 


PMADDUBSW Multiplies each unsigned byte value with the corresponding signed byte value to produce 
an intermediate, 16-bit signed integer. Each adjacent pair of 16-bit signed values are 
added horizontally. The signed, saturated 16-bit results are packed to the destination 
operand. 


5.8.4 Packed Multiply High with Round and Scale 


PMULHRSW Multiplies vertically each signed 16-bit integer from the destination operand with the corre- 
sponding signed 16-bit integer of the source operand, producing intermediate, signed 32- 
bit integers. Each intermediate 32-bit integer is truncated to the 18 most significant bits. 
Rounding is always performed by adding 1 to the least significant bit of the 18-bit interme- 
diate result. The final result is obtained by selecting the 16 bits immediately to the right of 
the most significant bit of each 18-bit intermediate result and packed to the destination 
operand. 


5.8.5 Packed Shuffle Bytes 


PSHUFB Permutes each byte in place, according to a shuffle control mask. The least significant 
three or four bits of each shuffle control byte of the control mask form the shuffle index. 
The shuffle mask is unaffected. If the most significant bit (bit 7) of a shuffle control byte is 
set, the constant zero is written in the result byte. 


5.8.6 Packed Sign 


PSIGNB/W/D Negates each signed integer element of the destination operand if the sign of the corre- 
sponding data element in the source operand is less than zero. 


5.8.7 Packed Align Right 


PALIGNR Source operand is appended after the destination operand forming an intermediate value 
of twice the width of an operand. The result is extracted from the intermediate value into 
the destination operand by selecting the 128 bit or 64 bit value that are right-aligned to the 
byte offset specified by the immediate value. 
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5.9 SSE4 INSTRUCTIONS 


Intel® Streaming SIMD Extensions 4 (SSE4) introduces 54 new instructions. 47 of the SSE4 instructions are 
referred to as SSE4.1 in this document, 7 new SSE4 instructions are referred to as SSE4.2. 


SSE4.1 is targeted to improve the performance of media, imaging, and 3D workloads. SSE4.1 adds instructions 
that improve compiler vectorization and significantly increase support for packed dword computation. The tech- 
nology also provides a hint that can improve memory throughput when reading from uncacheable WC memory 
type. 

The 47 SSE4.1 instructions include: 

* Two instructions perform packed dword multiplies. 

¢ Two instructions perform floating-point dot products with input/output selects. 

* One instruction performs a load with a streaming hint. 

¢ Six instructions simplify packed blending. 

¢ Eight instructions expand support for packed integer MIN/MAX. 

¢ Four instructions support floating-point round with selectable rounding mode and precision exception override. 
¢ Seven instructions improve data insertion and extractions from XMM registers 

°¢ Twelve instructions improve packed integer format conversions (sign and zero extensions). 

* One instruction improves SAD (sum absolute difference) generation for small block sizes. 

¢* One instruction aids horizontal searching operations. 

* One instruction improves masked comparisons. 

® One instruction adds qword packed equality comparisons. 

* One instruction adds dword packing with unsigned saturation. 

The SSE4.2 instructions operating on XMM registers include: 


¢ String and text processing that can take advantage of single-instruction multiple-data programming 
techniques. 


¢ ASIMD integer instruction that enhances the capability of the 128-bit integer SIMD capability in SSE4.1. 


5.10 SSE4.1 INSTRUCTIONS 


SSE4.1 instructions can use an XMM register as a source or destination. Programming SSE4.1 is similar to 
programming 128-bit Integer SIMD and floating-point SIMD instructions in SSE/SSE2/SSE3/SSSE3. SSE4.1 does 
not provide any 64-bit integer SIMD instructions operating on MMX registers. The sections that follow describe 
each subgroup. 


5.10.1 Dword Multiply Instructions 
PMULLD Returns four lower 32-bits of the 64-bit results of signed 32-bit integer multiplies. 
PMULDQ Returns two 64-bit signed result of signed 32-bit integer multiplies. 


5.10.2 Floating-Point Dot Product Instructions 
DPPD Perform double-precision dot product for up to 2 elements and broadcast. 
DPPS Perform single-precision dot products for up to 4 elements and broadcast. 


5.10.3. Streaming Load Hint Instruction 


MOVNTDQA Provides a non-temporal hint that can cause adjacent 16-byte items within an aligned 64- 
byte region (a streaming line) to be fetched and held in a small set of temporary buffers 
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(“streaming load buffers”). Subsequent streaming loads to other aligned 16-byte items in 
the same streaming line may be supplied from the streaming load buffer and can improve 
throughput. 


5.10.4 Packed Blending Instructions 


BLENDPD Conditionally copies specified double-precision floating-point data elements in the source 
operand to the corresponding data elements in the destination, using an immediate byte 
control. 

BLENDPS Conditionally copies specified single-precision floating-point data elements in the source 
operand to the corresponding data elements in the destination, using an immediate byte 
control. 

BLENDVPD Conditionally copies specified double-precision floating-point data elements in the source 
operand to the corresponding data elements in the destination, using an implied mask. 

BLENDVPS Conditionally copies specified single-precision floating-point data elements in the source 
operand to the corresponding data elements in the destination, using an implied mask. 

PBLENDVB Conditionally copies specified byte elements in the source operand to the corresponding 
elements in the destination, using an implied mask. 

PBLENDW Conditionally copies specified word elements in the source operand to the corresponding 


elements in the destination, using an immediate byte control. 


5.10.5 Packed Integer MIN/MAX Instructions 


PMINUW Compare packed unsigned word integers. 
PMINUD Compare packed unsigned dword integers. 
PMINSB Compare packed signed byte integers. 
PMINSD Compare packed signed dword integers. 
PMAXUW Compare packed unsigned word integers. 
PMAXUD Compare packed unsigned dword integers. 
PMAXSB Compare packed signed byte integers. 
PMAXSD Compare packed signed dword integers. 


5.10.6 Floating-Point Round Instructions with Selectable Rounding Mode 


ROUNDPS Round packed single precision floating-point values into integer values and return rounded 
floating-point values. 

ROUNDPD Round packed double precision floating-point values into integer values and return 
rounded floating-point values. 

ROUNDSS Round the low packed single precision floating-point value into an integer value and return 
a rounded floating-point value. 

ROUNDSD Round the low packed double precision floating-point value into an integer value and return 


a rounded floating-point value. 


5.10.7 Insertion and Extractions from XMM Registers 


EXTRACTPS Extracts a single-precision floating-point value from a specified offset in an XMM register 
and stores the result to memory or a general-purpose register. 
INSERTPS Inserts a single-precision floating-point value from either a 32-bit memory location or 


selected from a specified offset in an XMM register to a specified offset in the destination 
XMM register. In addition, INSERTPS allows zeroing out selected data elements in the desti- 
nation, using a mask. 
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Insert a byte value from a register or memory into an XMM register. 

Insert a dword value from 32-bit register or memory into an XMM register. 

Insert a qword value from 64-bit register or memory into an XMM register. 

Extract a byte from an XMM register and insert the value into a general-purpose register or 
memory. 

Extract a word from an XMM register and insert the value into a general-purpose register 
or memory. 

Extract a dword from an XMM register and insert the value into a general-purpose register 
or memory. 

Extract a qword from an XMM register and insert the value into a general-purpose register 
or memory. 


Packed Integer Format Conversions 


Sign extend the lower 8-bit integer of each packed word element into packed signed word 
integers. 

Zero extend the lower 8-bit integer of each packed word element into packed signed word 
integers. 

Sign extend the lower 8-bit integer of each packed dword element into packed signed 
dword integers. 

Zero extend the lower 8-bit integer of each packed dword element into packed signed 
dword integers. 

Sign extend the lower 16-bit integer of each packed dword element into packed signed 
dword integers. 

Zero extend the lower 16-bit integer of each packed dword element into packed signed 
dword integers.. 

Sign extend the lower 8-bit integer of each packed qword element into packed signed 
qword integers. 

Zero extend the lower 8-bit integer of each packed qword element into packed signed 
qword integers. 

Sign extend the lower 16-bit integer of each packed qword element into packed signed 
qword integers. 

Zero extend the lower 16-bit integer of each packed qword element into packed signed 
qword integers. 

Sign extend the lower 32-bit integer of each packed qword element into packed signed 
qword integers. 

Zero extend the lower 32-bit integer of each packed qword element into packed signed 
qword integers. 


Improved Sums of Absolute Differences (SAD) for 4-Byte Blocks 


Performs eight 4-byte wide Sum of Absolute Differences operations to produce eight word 
integers. 


5.10.10 Horizontal Search 


PHMINPOSUW 


Finds the value and location of the minimum unsigned word from one of 8 horizontally 
packed unsigned words. The resulting value and location (offset within the source) are 
packed into the low dword of the destination XMM register. 


Vol.1 5-27 


INSTRUCTION SET SUMMARY 


5.10.11 Packed Test 


PTEST Performs a logical AND between the destination with this mask and sets the ZF flag if the 
result is zero. The CF flag (zero for TEST) is set if the inverted mask AND’d with the desti- 
nation is all zeroes. 


5.10.12 Packed Qword Equality Comparisons 
PCMPEQQ 128-bit packed qword equality test. 


5.10.13 Dword Packing With Unsigned Saturation 
PACKUSDW PACKUSDW packs dword to word with unsigned saturation. 


5.11 SSE€4.2 INSTRUCTION SET 


Five of the SSE4.2 instructions operate on XMM register as a source or destination. These include four text/string 
processing instructions and one packed quadword compare SIMD instruction. Programming these five SSE4.2 
instructions is similar to programming 128-bit Integer SIMD in SSE2/SSSE3. SSE4.2 does not provide any 64-bit 
integer SIMD instructions. 


CRC32 operates on general-purpose registers and is summarized in Section 5.1.6. The sections that follow summa- 
rize each subgroup. 


5.11.1 String and Text Processing Instructions 


PCMPESTRI Packed compare explicit-length strings, return index in ECX/RCX. 
PCMPESTRM Packed compare explicit-length strings, return mask in XMMO. 
PCMPISTRI Packed compare implicit-length strings, return index in ECX/RCX. 
PCMPISTRM Packed compare implicit-length strings, return mask in XMMO. 


5.11.2 | Packed Comparison SIMD integer Instruction 
PCMPGTQ Performs logical compare of greater-than on packed integer quadwords. 


5.12 INTEL® AES-NI AND PCLMULQDQ 


Six Intel® AES-NI instructions operate on XMM registers to provide accelerated primitives for block encryp- 
tion/decryption using Advanced Encryption Standard (FIPS-197). The PCLMULQDQ instruction performs carry-less 
multiplication for two binary numbers up to 64-bit wide. 


AESDEC Perform an AES decryption round using an 128-bit state and a round key. 
AESDECLAST Perform the last AES decryption round using an 128-bit state and a round key. 
AESENC Perform an AES encryption round using an 128-bit state and a round key. 
AESENCLAST Perform the last AES encryption round using an 128-bit state and a round key. 
AESIMC Perform an inverse mix column transformation primitive. 

AESKEYGENASSIST Assist the creation of round keys with a key expansion schedule. 

PCLMULQDQ Perform carryless multiplication of two 64-bit numbers. 
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5.13. INTEL® ADVANCED VECTOR EXTENSIONS (INTEL® AVX) 


Intel® Advanced Vector Extensions (AVX) promotes legacy 128-bit SIMD instruction sets that operate on XMM 
register set to use a “vector extension“ (VEX) prefix and operates on 256-bit vector registers (YMM). Almost all 
prior generations of 128-bit SIMD instructions that operates on XMM (but not on MMX registers) are promoted to 
support three-operand syntax with VEX-128 encoding. 


VEX-prefix encoded AVX instructions support 256-bit and 128-bit floating-point operations by extending the legacy 
128-bit SIMD floating-point instructions to support three-operand syntax. 


Additional functional enhancements are also provided with VEX-encoded AVX instructions. 
The list of AVX instructions are listed in the following tables: 


° Table 14-2 lists 256-bit and 128-bit floating-point arithmetic instructions promoted from legacy 128-bit SIMD 
instruction sets. 


° Table 14-3 lists 256-bit and 128-bit data movement and processing instructions promoted from legacy 128-bit 
SIMD instruction sets. 


¢ Table 14-4 lists functional enhancements of 256-bit AVX instructions not available from legacy 128-bit SIMD 
instruction sets. 


¢ Table 14-5 lists 128-bit integer and floating-point instructions promoted from legacy 128-bit SIMD instruction 
sets. 


° Table 14-6 lists functional enhancements of 128-bit AVX instructions not available from legacy 128-bit SIMD 
instruction sets. 


° Table 14-7 lists 128-bit data movement and processing instructions promoted from legacy instruction sets. 


5.14  16-BIT FLOATING-POINT CONVERSION 


Conversion between single-precision floating-point (32-bit) and half-precision FP (16-bit) data are provided by 
VCVTPS2PH, VCVTPH2PS: 


VCVTPH2PS Convert eight/four data element containing 16-bit floating-point data into eight/four 
single-precision floating-point data. 
VCVTPS2PH Convert eight/four data element containing single-precision floating-point data into 


eight/four 16-bit floating-point data. 


5.15 | FUSED-MULTIPLY-ADD (FMA) 


FMA extensions enhances Intel AVX with high-throughput, arithmetic capabilities covering fused multiply-add, 
fused multiply-subtract, fused multiply add/subtract interleave, signed-reversed multiply on fused multiply-add 
and multiply-subtract. FMA extensions provide 36 256-bit floating-point instructions to perform computation on 
256-bit vectors and additional 128-bit and scalar FMA instructions. 


° §=Table 14-15 lists FMA instruction sets. 


5.16 INTEL® ADVANCED VECTOR EXTENSIONS 2 (INTEL® AVX2) 


Intel® AVX2 extends Intel AVX by promoting most of the 128-bit SIMD integer instructions with 256-bit numeric 
processing capabilities. Intel AVX2 instructions follow the same programming model as AVX instructions. 


In addition, AVX2 provide enhanced functionalities for broadcast/permute operations on data elements, vector 
shift instructions with variable-shift count per data element, and instructions to fetch non-contiguous data 
elements from memory. 


¢ Table 14-18 lists promoted vector integer instructions in AVX2. 
¢ Table 14-19 lists new instructions in AVX2 that complements AVX. 
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5.17 INTEL® TRANSACTIONAL SYNCHRONIZATION EXTENSIONS (INTEL® TSX) 


XABORT Abort an RTM transaction execution. 

XACQUIRE Prefix hint to the beginning of an HLE transaction region. 
XRELEASE Prefix hint to the end of an HLE transaction region. 
XBEGIN Transaction begin of an RTM transaction region. 

XEND Transaction end of an RTM transaction region. 

XTEST Test if executing in a transactional region. 


5.18 INTEL® SHA EXTENSIONS 


Intel® SHA extensions provide a set of instructions that target the acceleration of the Secure Hash Algorithm 
(SHA), specifically the SHA-1 and SHA-256 variants. 


SHA1MSG1 Perform an intermediate calculation for the next four SHA1 message dwords from the 
previous message dwords. 

SHA1MSG2 Perform the final calculation for the next four SHA1 message dwords from the intermediate 
message dwords. 

SHA1NEXTE Calculate SHA1 state E after four rounds. 

SHA1RNDS4 Perform four rounds of SHA1 operations. 

SHA256MSG1 Perform an intermediate calculation for the next four SHA256 message dwords. 

SHA256MSG2 Perform the final calculation for the next four SHA256 message dwords. 

SHA256RNDS2 Perform two rounds of SHA256 operations. 


5.19 INTEL® ADVANCED VECTOR EXTENSIONS 512 (INTEL® AVX-512) 


The Intel® AVX-512 family comprises a collection of 512-bit SIMD instruction sets to accelerate a diverse range of 
applications. Intel AVX-512 instructions provide a wide range of functionality that support programming in 512-bit, 
256 and 128-bit vector register, plus support for opmask registers and instructions operating on opmask registers. 


The collection of 512-bit SIMD instruction sets in Intel AVX-512 include new functionality not available in Intel AVX 
and Intel AVX2, and promoted instructions similar to equivalent ones in Intel AVX / Intel AVX2 but with enhance- 
ment provided by opmask registers not available to VEX-encoded Intel AVX / Intel AVX2. Some instruction 
mnemonics in AVX / AVX2 that are promoted into AVX-512 can be replaced by new instruction mnemonics that are 
available only with EVEX encoding, e.g., VBROADCASTF128 into VBROADCASTF324. Details of EVEX instruction 
encoding are discussed in Section 2.6, “Intel® AVX-512 Encoding” of the Inte/® 64 and IA-32 Architectures Soft- 
ware Developer’s Manual, Volume 2A. 


512-bit instruction mnemonics in AVX-512F that are not AVX/AVX2 promotions include: 


VALIGND/Q Perform dword/qword alignment of two concatenated source vectors. 
VBLENDMPD/PS Replace the VBLENDVPD/PS instructions (using opmask as select control). 
VCOMPRESSPD/PS Compress packed DP or SP elements of a vector. 

VCVT(T)PD2UDQ Convert packed DP FP elements of a vector to packed unsigned 32-bit integers. 
VCVT(T)PS2UDQ Convert packed SP FP elements of a vector to packed unsigned 32-bit integers. 
VCVTQQ2PD/PS Convert packed signed 64-bit integers to packed DP/SP FP elements. 
VCVT(T)SD2USI Convert the low DP FP element of a vector to an unsigned integer. 
VCVT(T)SS2USI Convert the low SP FP element of a vector to an unsigned integer. 
VCVTUDQ2PD/PS Convert packed unsigned 32-bit integers to packed DP/SP FP elements. 
VCVTUSI2USD/S Convert an unsigned integer to the low DP/SP FP element and merge to a vector. 
VEXPANDPD/PS Expand packed DP or SP elements of a vector. 


VEXTRACTF32X4/64X4 Extract a vector from a full-length vector with 32/64-bit granular update. 
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VEXTRACTI32X4/64X4 Extract a vector from a full-length vector with 32/64-bit granular update. 


VFIXUPIMMPD/PS 
VFIXUPIMMSD/SS 
VGETEXPPD/PS 
VGETEXPSD/SS 
VGETMANTPD/PS 
VGETMANTSD/SS 


VINSERTF32X4/64X4 


VMOVDQA32/64 
VMOVDQU32/64 
VPBLENDMD/Q 
VPBROADCASTD/Q 
VPCMPD/UD 
VPCMPQ/UQ 
VPCOMPRESSQ/D 
VPERMI2D/Q 
VPERMI2PD/PS 
VPERMT2D/Q 
VPERMT2PD/PS 
VPEXPANDD/Q 
VPMAXSQ 
VPMAXUD/UQ 
VPMINSQ 
VPMINUD/UQ 
VPMOV(S|US)QB 


VPMOV(S|US)QW 
VPMOV(S|US)QD 
VPMOV(S|US)DB 
VPMOV(S|US)DW 


VPROLD/Q 
VPROLVD/Q 


VPRORD/Q 
VPRORRD/Q 


VPSCATTERDD/DQ 
VPSCATTERQD/QQ 
VPSRAQ 

VPSRAVQ 
VPTESTNMD/Q 


VPTERLOGD/Q 


Perform fix-up to special values in DP/SP FP vectors. 

Perform fix-up to special values of the low DP/SP FP element. 

Convert the exponent of DP/SP FP elements of a vector into FP values. 

Convert the exponent of the low DP/SP FP element in a vector into FP value. 
Convert the mantissa of DP/SP FP elements of a vector into FP values. 

Convert the mantissa of the low DP/SP FP element of a vector into FP value. 
Insert a 128/256-bit vector into a full-length vector with 32/64-bit granular update. 
VMOVDQA with 32/64-bit granular conditional update. 

VMOVDQU with 32/64-bit granular conditional update. 

Blend dword/qword elements using opmask as select control. 

Broadcast from general-purpose register to vector register. 

Compare packed signed/unsigned dwords using specified primitive. 

Compare packed signed/unsigned quadwords using specified primitive. 
Compress packed 64/32-bit elements of a vector. 

Full permute of two tables of dword/qword elements overwriting the index vector. 
Full permute of two tables of DP/SP elements overwriting the index vector. 

Full permute of two tables of dword/qword elements overwriting one source table. 
Full permute of two tables of DP/SP elements overwriting one source table. 
Expand packed dword/qword elements of a vector. 

Compute maximum of packed signed 64-bit integer elements. 

Compute maximum of packed unsigned 32/64-bit integer elements. 

Compute minimum of packed signed 64-bit integer elements. 

Compute minimum of packed unsigned 32/64-bit integer elements. 


Down convert qword elements in a vector to byte elements using truncation (saturation | 
unsigned saturation). 


Down convert qword elements in a vector to word elements using truncation (saturation | 
unsigned saturation). 


Down convert qword elements in a vector to dword elements using truncation (saturation 
| unsigned saturation). 


Down convert dword elements in a vector to byte elements using truncation (saturation | 
unsigned saturation). 


Down convert dword elements in a vector to word elements using truncation (saturation | 
unsigned saturation). 


Rotate dword/qword element left by a constant shift count with conditional update. 


Rotate dword/qword element left by shift counts specified in a vector with conditional 
update. 


Rotate dword/qword element right by a constant shift count with conditional update. 


Rotate dword/qword element right by shift counts specified in a vector with conditional 
update. 


Scatter dword/qword elements in a vector to memory using dword indices. 
Scatter dword/qword elements in a vector to memory using qword indices. 
Shift qwords right by a constant shift count and shifting in sign bits. 

Shift qwords right by shift counts in a vector and shifting in sign bits. 


Perform bitwise NAND of dword/qword elements of two vectors and write results to 
opmask. 


Perform bitwise ternary logic operation of three vectors with 32/64 bit granular conditional 
update. 
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VPTESTMD/Q 
VRCP14PD/PS 
VRCP14SD/SS 
VRNDSCALEPD/PS 
VRNDSCALESD/SS 
VRSQRT14PD/PS 
VRSQRT14SD/SS 


VSCALEPD/PS 
VSCALESD/SS 


VSCATTERDD/DQ 
VSCATTERQD/QQ 
VSHUFF32X4/64X2 
VSHUFI32X4/64X2 


Perform bitwise AND of dword/qword elements of two vectors and write results to opmask. 
Compute approximate reciprocals of packed DP/SP FP elements of a vector. 

Compute the approximate reciprocal of the low DP/SP FP element of a vector. 

Round packed DP/SP FP elements of a vector to specified number of fraction bits. 

Round the low DP/SP FP element of a vector to specified number of fraction bits. 
Compute approximate reciprocals of square roots of packed DP/SP FP elements of a vector. 


Compute the approximate reciprocal of square root of the low DP/SP FP element of a 
vector. 


Multiply packed DP/SP FP elements of a vector by powers of two with exponents specified 
in a second vector. 


Multiply the low DP/SP FP element of a vector by powers of two with exponent specified in 
the corresponding element of a second vector. 


Scatter SP/DP FP elements in a vector to memory using dword indices. 
Scatter SP/DP FP elements in a vector to memory using qword indices. 
Shuffle 128-bit lanes of a vector with 32/64 bit granular conditional update. 
Shuffle 128-bit lanes of a vector with 32/64 bit granular conditional update. 


512-bit instruction mnemonics in AVX-512DQ that are not AVX/AVX2 promotions include: 


VCVT(T)PD2QQ 
VCVT(T)PD2UQQ 
VCVT(T)PS2QQ 
VCVT(T)PS2UQQ 
VCVTUQQ2PD/PS 
VEXTRACTF64X2 
VEXTRACTI64X2 
VFPCLASSPD/PS 
VFPCLASSSD/SS 
VINSERTF64X2 
VINSERTI64X2 
VPMOVM2D/Q 
VPMOVB2D/Q2M 
VPMULLQ 


VRANGEPD/PS 
VRANGESD/SS 
VREDUCEPD/PS 


VREDUCESD/SS 


Convert packed DP FP elements of a vector to packed signed 64-bit integers. 

Convert packed DP FP elements of a vector to packed unsigned 64-bit integers. 

Convert packed SP FP elements of a vector to packed signed 64-bit integers. 

Convert packed SP FP elements of a vector to packed unsigned 64-bit integers. 

Convert packed unsigned 64-bit integers to packed DP/SP FP elements. 

Extract a vector from a full-length vector with 64-bit granular update. 

Extract a vector from a full-length vector with 64-bit granular update. 

Test packed DP/SP FP elements in a vector by numeric/special-value category. 

Test the low DP/SP FP element by numeric/special-value category. 

Insert a 128-bit vector into a full-length vector with 64-bit granular update. 

Insert a 128-bit vector into a full-length vector with 64-bit granular update. 

Convert opmask register to vector register in 32/64-bit granularity. 

Convert a vector register in 32/64-bit granularity to an opmask register. 

Multiply packed signed 64-bit integer elements of two vectors and store low 64-bit signed 
result. 

Perform RANGE operation on each pair of DP/SP FP elements of two vectors using specified 
range primitive in imm8. 

Perform RANGE operation on the pair of low DP/SP FP element of two vectors using speci- 
fied range primitive in imms. 

Perform Reduction operation on packed DP/SP FP elements of a vector using specified 
reduction primitive in imms. 

Perform Reduction operation on the low DP/SP FP element of a vector using specified 
reduction primitive in imms. 


512-bit instruction mnemonics in AVX-512BW that are not AVX/AVX2 promotions include: 


VDBPSADBW 
VMOVDQU8/16 
VPBLENDMB 
VPBLENDMW 
VPBROADCASTB/W 
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Double block packed Sum-Absolute-Differences on unsigned bytes. 
VMOVDQU with 8/16-bit granular conditional update. 

Replaces the VPBLENDVB instruction (using opmask as select control). 
Blend word elements using opmask as select control. 

Broadcast from general-purpose register to vector register. 


VPCMPB/UB 
VPCMPW/UW 
VPERMW 
VPERMI2B/W 
VPMOVM2B/W 
VPMOVB2M/W2M 
VPMOV(S|US)WB 


VPSLLVW 
VPSRAVW 
VPSRLVW 
VPTESTNMB/W 
VPTESTMB/W 


INSTRUCTION SET SUMMARY 


Compare packed signed/unsigned bytes using specified primitive. 

Compare packed signed/unsigned words using specified primitive. 

Permute packed word elements. 

Full permute from two tables of byte/word elements overwriting the index vector. 
Convert opmask register to vector register in 8/16-bit granularity. 

Convert a vector register in 8/16-bit granularity to an opmask register. 


Down convert word elements in a vector to byte elements using truncation (saturation | 
unsigned saturation). 


Shift word elements in a vector left by shift counts in a vector. 

Shift words right by shift counts in a vector and shifting in sign bits. 

Shift word elements in a vector right by shift counts in a vector. 

Perform bitwise NAND of byte/word elements of two vectors and write results to opmask. 
Perform bitwise AND of byte/word elements of two vectors and write results to opmask. 


512-bit instruction mnemonics in AVX-512CD that are not AVX/AVX2 promotions include: 


VPBROADCASTM 
VPCONFLICTD/Q 
VPLZCNTD/Q 


Broadcast from opmask register to vector register. 
Detect conflicts within a vector of packed 32/64-bit integers. 
Count the number of leading zero bits of packed dword/qword elements. 


Opmask instructions include: 


KADDB/W/D/Q 
KANDB/W/D/Q 
KANDNB/W/D/Q 
KMOVB/W/D/Q 
KNOTB/W/D/Q 
KORB/W/D/Q 
KORTESTB/W/D/Q 
KSHIFTLB/W/D/Q 
KSHIFTRB/W/D/Q 
KTESTB/W/D/Q 


KUNPCKBW/WD/DQ 


KXNORB/W/D/Q 
KXORB/W/D/Q 


Add two 8/16/32/64-bit opmasks. 

Logical AND two 8/16/32/64-bit opmasks. 

Logical AND NOT two 8/16/32/64-bit opmasks. 

Move from or move to opmask register of 8/16/32/64-bit data. 

Bitwise NOT of two 8/16/32/64-bit opmasks. 

Logical OR two 8/16/32/64-bit opmasks. 

Update EFLAGS according to the result of bitwise OR of two 8/16/32/64-bit opmasks. 
Shift left 8/16/32/64-bit opmask by specified count. 

Shift right 8/16/32/64-bit opmask by specified count. 

Update EFLAGS according to the result of bitwise TEST of two 8/16/32/64-bit opmasks. 
Unpack and interleave two 8/16/32-bit opmasks into 16/32/64-bit mask. 

Bitwise logical XNOR of two 8/16/32/64-bit opmasks. 

Logical XOR of two 8/16/32/64-bit opmasks. 


512-bit instruction mnemonics in AVX-512ER include: 


VEXP2PD/PS 
VEXP2SD/SS 
VRCP28PD/PS 
VRCP28SD/SS 
VRSQRT28PD/PS 


VRSQRT28SD/SS 


Compute approximate base-2 exponential of packed DP/SP FP elements of a vector. 
Compute approximate base-2 exponential of the low DP/SP FP element of a vector. 
Compute approximate reciprocals to 28 bits of packed DP/SP FP elements of a vector. 
Compute the approximate reciprocal to 28 bits of the low DP/SP FP element of a vector. 


Compute approximate reciprocals of square roots to 28 bits of packed DP/SP FP elements 
of a vector. 


Compute the approximate reciprocal of square root to 28 bits of the low DP/SP FP element 
of a vector. 


512-bit instruction mnemonics in AVX-512PF include: 


VGATHERPFODPD/PS 


Sparse prefetch of packed DP/SP FP vector with TO hint using dword indices. 
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VGATHERPFOQPD/PS 
VGATHERPF1DPD/PS 
VGATHERPF1QPD/PS 
VSCATTERPFODPD/PS 
VSCATTERPFOQPD/PS 
VSCATTERPF1DPD/PS 
VSCATTERPF1QPD/PS 


Sparse prefetch of packed DP/SP FP vector with TO hint using qword indices. 
Sparse prefetch of packed DP/SP FP vector with T1 hint using dword indices. 
Sparse prefetch of packed DP/SP FP vector with T1 hint using qword indices. 
Sparse prefetch of packed DP/SP FP vector with TO hint to write using dword indices. 
Sparse prefetch of packed DP/SP FP vector with TO hint to write using qword indices. 
Sparse prefetch of packed DP/SP FP vector with Ti hint to write using dword indices. 
Sparse prefetch of packed DP/SP FP vector with T1 hint to write using qword indices. 


5.20 SYSTEM INSTRUCTIONS 


The following system instructions are used to control those functions of the processor that are provided to support 
for operating systems and executives. 


CLAC 
STAC 
LGDT 
SGDT 
LLDT 
SLDT 
LTR 
STR 
LIDT 
SIDT 
MOV 
LMSW 
SMSW 


LSL 

VERR 

VERW 

MOV 

INVD 
WBINVD 
INVLPG 
INVPCID 
LOCK (prefix) 


HLT 

RSM 
RDMSR 
WRMSR 
RDPMC 
RDTSC 
RDTSCP 
SYSENTER 
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Clear AC Flag in EFLAGS register. 

Set AC Flag in EFLAGS register. 

Load global descriptor table (GDT) register. 
Store global descriptor table (GDT) register. 
Load local descriptor table (LDT) register. 
Store local descriptor table (LDT) register. 
Load task register. 

Store task register. 

Load interrupt descriptor table (IDT) register. 
Store interrupt descriptor table (IDT) register. 
Load and store control registers. 

Load machine status word. 

Store machine status word. 

Clear the task-switched flag. 

Adjust requested privilege level. 

Load access rights. 

Load segment limit. 

Verify segment for reading 

Verify segment for writing. 

Load and store debug registers. 

Invalidate cache, no writeback. 

Invalidate cache, with writeback. 

Invalidate TLB Entry. 

Invalidate Process-Context Identifier. 


Perform atomic access to memory (can be applied to a number of general purpose instruc- 
tions that provide memory source/destination access). 


Halt processor. 

Return from system management mode (SMM). 

Read model-specific register. 

Write model-specific register. 

Read performance monitoring counters. 

Read time stamp counter. 

Read time stamp counter and processor ID. 

Fast System Call, transfers to a flat protected mode kernel at CPL = 0. 


SYSEXIT 
XSAVE 
XSAVEC 
XSAVEOPT 
XSAVES 
XRSTOR 
XRSTORS 
XGETBV 
XSETBV 
RDFSBASE 
RDGSBASE 
WRFSBASE 
WRGSBASE 


INSTRUCTION SET SUMMARY 


Fast System Call, transfers to a flat protected mode kernel at CPL = 3. 
Save processor extended states to memory. 

Save processor extended states with compaction to memory. 

Save processor extended states to memory, optimized. 

Save processor supervisor-mode extended states to memory. 
Restore processor extended states from memory. 

Restore processor supervisor-mode extended states from memory. 
Reads the state of an extended control register. 

Writes the state of an extended control register. 

Reads from FS base address at any privilege level. 

Reads from GS base address at any privilege level. 

Writes to FS base address at any privilege level. 

Writes to GS base address at any privilege level. 


5.21 64-BIT MODE INSTRUCTIONS 


The following instructions are introduced in 64-bit mode. This mode is a sub-mode of IA-32e mode. 


CDQE 

CMPSQ 
CMPXCHG16B 
LODSQ 

MOVSQ 

MOVZX (64-bits) 
STOSQ 
SWAPGS 
SYSCALL 
SYSRET 


Convert doubleword to quadword. 

Compare string operands. 

Compare RDX:RAX with m128. 

Load qword at address (R)SI into RAX. 

Move qword from address (R)SI to (R)DI. 

Move bytes/words to doublewords/quadwords, zero-extension. 

Store RAX at address RDI. 

Exchanges current GS base register value with value in MSR address CO000102H. 
Fast call to privilege level 0 system procedures. 

Return from fast systemcall. 


5.22 VIRTUAL-MACHINE EXTENSIONS 


The behavior of the VMCS-maintenance instructions is summarized below: 


VMPTRLD 


VMPTRST 


VMCLEAR 


VMREAD 


VMWRITE 


Takes a single 64-bit source operand in memory. It makes the referenced VMCS active and 
current. 

Takes a single 64-bit destination operand that is in memory. Current-VMCS pointer is 
stored into the destination operand. 

Takes a single 64-bit operand in memory. The instruction sets the launch state of the VMCS 
referenced by the operand to “clear”, renders that VMCS inactive, and ensures that data 
for the VMCS have been written to the VMCS-data area in the referenced VMCS region. 
Reads a component from the VMCS (the encoding of that field is given in a register 
operand) and stores it into a destination operand. 

Writes a component to the VMCS (the encoding of that field is given in a register operand) 
from a source operand. 


The behavior of the VMX management instructions is summarized below: 


VMLAUNCH 


VMRESUME 


Launches a virtual machine managed by the VMCS. AVM entry occurs, transferring control 
to the VM. 


Resumes a virtual machine managed by the VMCS. A VM entry occurs, transferring control 
to the VM. 
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VMXOFF Causes the processor to leave VMX operation. 

VMXON Takes a single 64-bit source operand in memory. It causes a logical processor to enter VMX 
root operation and to use the memory referenced by the operand to support VMX opera- 
tion. 


The behavior of the VMX-specific TLB-management instructions is summarized below: 


INVEPT Invalidate cached Extended Page Table (EPT) mappings in the processor to synchronize 
address translation in virtual machines with memory-resident EPT pages. 

INVVPID Invalidate cached mappings of address translation based on the Virtual Processor ID 
(VPID). 


None of the instructions above can be executed in compatibility mode; they generate invalid-opcode exceptions if 
executed in compatibility mode. 


The behavior of the guest-available instructions is summarized below: 


VMCALL Allows a guest in VMX non-root operation to call the VMM for service. A VM exit occurs, 
transferring control to the VMM. 
VMFUNC This instruction allows software in VMX non-root operation to invoke a VM function, which 


is processor functionality enabled and configured by software in VMX root operation. No 
VM exit occurs. 


5.23 SAFER MODE EXTENSIONS 


The behavior of the GETSEC instruction leaves of the Safer Mode Extensions (SMX) are summarized below: 
GETSEC[CAPABILITIES]Returns the available leaf functions of the GETSEC instruction. 
GETSEC[ENTERACCS] Loads an authenticated code chipset module and enters authenticated code execution 


mode. 

GETSEC[EXITAC] Exits authenticated code execution mode. 

GETSEC[SENTER] Establishes a Measured Launched Environment (MLE) which has its dynamic root of trust 
anchored to a chipset supporting Intel Trusted Execution Technology. 

GETSEC[SEXIT] Exits the MLE. 

GETSEC[PARAMETERS] Returns SMX related parameter information. 

GETSEC[SMCRTL] SMX mode control. 

GETSEC[WAKEUP] Wakes up sleeping logical processors inside an MLE. 


5.24 INTEL® MEMORY PROTECTION EXTENSIONS 


Intel Memory Protection Extensions (MPX) provides a set of instructions to enable software to add robust bounds 
checking capability to memory references. Details of Intel MPX are described in Chapter 17, “Intel® MPX”. 


BNDMK Create a LowerBound and a UpperBound in a register. 

BNDCL Check the address of a memory reference against a LowerBound. 

BNDCU Check the address of a memory reference against an UpperBound in 1’s compliment form. 

BNDCN Check the address of a memory reference against an UpperBound not in 1’s compliment 
form. 

BNDMOV Copy or load from memory of the LowerBound and UpperBound to a register. 

BNDMOV Store to memory of the LowerBound and UpperBound from a register. 

BNDLDX Load bounds using address translation. 

BNDSTX Store bounds using address translation. 
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INTEL® SOFTWARE GUARD EXTENSIONS 
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Intel Software Guard Extensions (Intel SGX) provide two sets of instruction leaf functions to enable application 
software to instantiate a protected container, referred to as an enclave. The enclave instructions are organized as 
leaf functions under two instruction mnemonics: ENCLS (ring 0) and ENCLU (ring 3). Details of Intel SGX are 
described in CHAPTER 32 through CHAPTER 38 of Inte/® 64 and IA-32 Architectures Software Developer’s 


Manual, Volume 3D. 


The first implementation of Intel SGX is also referred to as SGX1, it is introduced with the 6th Generation Intel 
Core Processors. The leaf functions supported in SGX1 is shown in Table 5-3. 


Table 5-3. Supervisor and User Mode Enclave Instruction Leaf Functions in Long-Form of SGX1 


Supervisor Instruction Description User Instruction Description 
ENCLS[EADD] Add a page ENCLU[EENTER] Enter an Enclave 
ENCLS[EBLOCK] Block an EPC page ENCLU[EEXIT] Exit an Enclave 
ENCLS[ECREATE] Create an enclave ENCLU[EGETKEY] Create a cryptographic key 
ENCLS[EDBGRD] Read data by debugger ENCLU[EREPORT] Create a cryptographic report 
ENCLS[EDBGWR] Write data by debugger ENCLU[ERESUME] Re-enter an Enclave 
ENCLS[EEXTEND] Extend EPC page measurement 
ENCLS[EINIT] Initialize an enclave 
ENCLS[ELDB] Load an EPC page as blocked 
ENCLS[ELDU] Load an EPC page as unblocked 
ENCLS[EPA] Add version array 
ENCLS[EREMOVE] Remove a page from EPC 
ENCLS[ETRACK] Activate EBLOCK checks 
ENCLS[EWB] Write back/invalidate an EPC page 

5.26 SHADOW STACK MANAGEMENT INSTRUCTIONS 


Shadow stack management instructions allow the program and run-time to perform operations like recovering 
from control protection faults, shadow stack switching, etc. The following instructions are provided. 


Clear busy bit in a supervisor shadow stack token. 
Increment the shadow stack pointer (SSP). 


CLRSSBSY 
INCSSP 
RDSSP 
RSTORSSP 
SAVEPREVSSP 
SETSSBSY 
WRSS 

WRUSS 
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ENDBR32 
ENDBR64 


Read shadow stack point (SSP). 


Restore a shadow stack pointer (SSP). 
Save previous shadow stack pointer (SSP). 
Set busy bit in a supervisor shadow stack token. 


Write to a shadow stack. 


Write to a user mode shadow stack. 


CONTROL TRANSFER TERMINATING INSTRUCTIONS 


Terminate an Indirect Branch in 32-bit and Compatibility Mode. 
Terminate an Indirect Branch in 64-bit Mode. 
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CHAPTER 6 
PROCEDURE CALLS, INTERRUPTS, AND EXCEPTIONS 


This chapter describes the facilities in the Intel 64 and IA-32 architectures for executing calls to procedures or 
subroutines. It also describes how interrupts and exceptions are handled from the perspective of an application 
programmer. 


6.1 PROCEDURE CALL TYPES 


The processor supports procedure calls in the following two different ways: 
® CALL and RET instructions. 


¢ ENTER and LEAVE instructions, in conjunction with the CALL and RET 
instructions. 


Both of these procedure call mechanisms use the procedure stack, commonly referred to simply as “the stack,” to 
save the state of the calling procedure, pass parameters to the called procedure, and store local variables for the 
currently executing procedure. 


The processor’s facilities for handling interrupts and exceptions are similar to those used by the CALL and RET 
instructions. 


Processors that support Control-Flow Enforcement Technology (CET) support an additional stack referred to as “the 
shadow stack”. The CALL instruction, when shadow stacks are enabled, additionally saves the state of the calling 
procedure on the shadow stack; and the RET instruction restores the state of the calling procedure if the state on 
the stack and the shadow stack match. 


6.2 STACKS 


The stack (see Figure 6-1) is a contiguous array of memory locations. It is contained in a segment and identified by 
the segment selector in the SS register. When using the flat memory model, the stack can be located anywhere in 
the linear address space for the program. A stack can be up to 4 GBytes long, the maximum size of a segment. 


Items are placed on the stack using the PUSH instruction and removed from the stack using the POP instruction. 
When an item is pushed onto the stack, the processor decrements the ESP register, then writes the item at the new 
top of stack. When an item is popped off the stack, the processor reads the item from the top of stack, then incre- 
ments the ESP register. In this manner, the stack grows down in memory (towards lesser addresses) when items 
are pushed on the stack and shrinks up (towards greater addresses) when the items are popped from the stack. 


A program or operating system/executive can set up many stacks. For example, in multitasking systems, each task 
can be given its own stack. The number of stacks in a system is limited by the maximum number of segments and 
the available physical memory. 


When a system sets up many stacks, only one stack—the current stack—is available at a time. The current stack 
is the one contained in the segment referenced by the SS register. 
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Figure 6-1. Stack Structure 


The processor references the SS register automatically for all stack operations. For example, when the ESP register 
is used as a memory address, it automatically points to an address in the current stack. Also, the CALL, RET, PUSH, 
POP, ENTER, and LEAVE instructions all perform operations on the current stack. 


6.2.1 Setting Up a Stack 


To set a stack and establish it as the current stack, the program or operating system/executive must do the 
following: 


1. Establish a stack segment. 
2. Load the segment selector for the stack segment into the SS register using a MOV, POP, or LSS instruction. 


3. Load the stack pointer for the stack into the ESP register using a MOV, POP, or LSS instruction. The LSS 
instruction can be used to load the SS and ESP registers in one operation. 


See “Segment Descriptors” in Chapter 3, “Protected-Mode Memory Management,” of the Inte/® 64 and IA-32 
Architectures Software Developer’s Manual, Volume 3A, for information on how to set up a segment descriptor and 
segment limits for a stack segment. 


6.2.2 Stack Alignment 


The stack pointer for a stack segment should be aligned on 16-bit (word) or 32-bit (double-word) boundaries, 
depending on the width of the stack segment. The D flag in the segment descriptor for the current code segment 
sets the stack-segment width (see “Segment Descriptors” in Chapter 3, “Protected-Mode Memory Management,” of 
the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A). The PUSH and POP instructions 
use the D flag to determine how much to decrement or increment the stack pointer on a push or pop operation, 
respectively. When the stack width is 16 bits, the stack pointer is incremented or decremented in 16-bit increments; 
when the width is 32 bits, the stack pointer is incremented or decremented in 32-bit increments. Pushing a 16-bit 
value onto a 32-bit wide stack can result in stack misaligned (that is, the stack pointer is not aligned on a double- 
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word boundary). One exception to this rule is when the contents of a segment register (a 16-bit segment selector) 
are pushed onto a 32-bit wide stack. Here, the processor automatically aligns the stack pointer to the next 32-bit 
boundary. 


The processor does not check stack pointer alignment. It is the responsibility of the programs, tasks, and system 
procedures running on the processor to maintain proper alignment of stack pointers. Misaligning a stack pointer 
can cause serious performance degradation and in some instances program failures. 


6.2.3 Address-Size Attributes for Stack Accesses 


Instructions that use the stack implicitly (such as the PUSH and POP instructions) have two address-size attributes 
each of either 16 or 32 bits. This is because they always have the implicit address of the top of the stack, and they 
may also have an explicit memory address (for example, PUSH Array1[EBX]). The attribute of the explicit address 
is determined by the D flag of the current code segment and the presence or absence of the 67H address-size 
prefix. 


The address-size attribute of the top of the stack determines whether SP or ESP is used for the stack access. Stack 
operations with an address-size attribute of 16 use the 16-bit SP stack pointer register and can use a maximum 
stack address of FFFFH; stack operations with an address-size attribute of 32 bits use the 32-bit ESP register and 
can use a maximum address of FFFFFFFFH. The default address-size attribute for data segments used as stacks is 
controlled by the B flag of the segment’s descriptor. When this flag is clear, the default address-size attribute is 16; 
when the flag is set, the address-size attribute is 32. 


6.2.4 Procedure Linking Information 


The processor provides two pointers for linking of procedures: the stack-frame base pointer and the return instruc- 
tion pointer. When used in conjunction with a standard software procedure-call technique, these pointers permit 
reliable and coherent linking of procedures. 


6.2.4.1 Stack-Frame Base Pointer 


The stack is typically divided into frames. Each stack frame can then contain local variables, parameters to be 
passed to another procedure, and procedure linking information. The stack-frame base pointer (contained in the 
EBP register) identifies a fixed reference point within the stack frame for the called procedure. To use the stack- 
frame base pointer, the called procedure typically copies the contents of the ESP register into the EBP register prior 
to pushing any local variables on the stack. The stack-frame base pointer then permits easy access to data struc- 
tures passed on the stack, to the return instruction pointer, and to local variables added to the stack by the called 
procedure. 


Like the ESP register, the EBP register automatically points to an address in the current stack segment (that is, the 
segment specified by the current contents of the SS register). 


6.2.4.2 Return Instruction Pointer 


Prior to branching to the first instruction of the called procedure, the CALL instruction pushes the address in the EIP 
register onto the current stack. This address is then called the return-instruction pointer and it points to the 
instruction where execution of the calling procedure should resume following a return from the called procedure. 
Upon returning from a called procedure, the RET instruction pops the return-instruction pointer from the stack back 
into the EIP register. Execution of the calling procedure then resumes. 


The processor does not keep track of the location of the return-instruction pointer. It is thus up to the programmer 
to ensure that stack pointer is pointing to the return-instruction pointer on the stack, prior to issuing a RET instruc- 
tion. A common way to reset the stack pointer to the point to the return-instruction pointer is to move the contents 
of the EBP register into the ESP register. If the EBP register is loaded with the stack pointer immediately following 
a procedure call, it should point to the return instruction pointer on the stack. 


The processor does not require that the return instruction pointer point back to the calling procedure. Prior to 
executing the RET instruction, the return instruction pointer can be manipulated in software to point to any address 
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in the current code segment (near return) or another code segment (far return). Performing such an operation, 
however, should be undertaken very cautiously, using only well defined code entry points. 


6.2.5 Stack Behavior in 64-Bit Mode 


In 64-bit mode, address calculations that reference SS segments are treated as if the segment base is zero. Fields 
(base, limit, and attribute) in segment descriptor registers are ignored. SS DPL is modified such that it is always 
equal to CPL. This will be true even if it is the only field in the SS descriptor that is modified. 


Registers E(SP), E(IP) and E(BP) are promoted to 64-bits and are re-named RSP, RIP, and RBP respectively. Some 
forms of segment load instructions are invalid (for example, LDS, POP ES). 


PUSH/POP instructions increment/decrement the stack using a 64-bit width. When the contents of a segment 
register is pushed onto 64-bit stack, the pointer is automatically aligned to 64 bits (as with a stack that has a 32- 
bit width). 


6.3 SHADOW STACKS 


A shadow stack is a second stack used exclusively for control transfer operations. This stack is separate from the 
procedure stack. The shadow stack is not used to store data, hence is not explicitly writeable by software. Writes 
to the shadow stack are restricted to control transfer instructions and shadow stack management instructions. 
Shadow stacks can be enabled separately for privilege level 3 (user mode) or privilege levels less than 3 (super- 
visor mode). 


Shadow stacks are active only in protected mode with paging enabled. Shadow stacks cannot be enabled for a 
program executing in virtual 8086 mode. 


Processors that support shadow stacks have an architectural register called the shadow stack pointer (SSP) that 
points to the current top of the shadow stack. The SSP cannot be directly encoded as a source, destination, or 
memory operand in instructions. The width of the shadow stack is 32-bit in 32-bit/compatibility mode, and is 64- 
bit in 64-bit mode. The address-size attribute of the shadow stack is likewise 32-bit in 32-bit/compatibility mode, 
and 64-bit in 64-bit mode. 


The size of the shadow stack pushes and pops for far CALL and call to interrupt/exception handlers is fixed at 64 
bits, and the processor uses 8-byte, zero padded stores for these pushes in 32-bit/compatibility modes. 


6.4 CALLING PROCEDURES USING CALL AND RET 


The CALL instruction allows control transfers to procedures within the current code segment (near call) and ina 
different code segment (far call). Near calls usually provide access to local procedures within the currently running 
program or task. Far calls are usually used to access operating system procedures or procedures in a different task. 
See “CALL—Call Procedure” in Chapter 3, “Instruction Set Reference, A-L,” of the Inte/® 64 and IA-32 Architectures 
Software Developer’s Manual, Volume 2A, for a detailed description of the CALL instruction. 


The RET instruction also allows near and far returns to match the near and far versions of the CALL instruction. In 
addition, the RET instruction allows a program to increment the stack pointer on a return to release parameters 
from the stack. The number of bytes released from the stack is determined by an optional argument (/n) to the RET 
instruction. See “RET—Return from Procedure” in Chapter 4, “Instruction Set Reference, M-U,” of the Inte/® 64 and 
IA-32 Architectures Software Developer’s Manual, Volume 2B, for a detailed description of the RET instruction. 


6.4.1 Near CALL and RET Operation 
When executing a near call, the processor does the following (see Figure 6-2): 
1. Pushes the current value of the EIP register on the stack. 


If shadow stack is enabled and the displacement value is not 0, pushes the current value of the EIP register on 
the shadow stack. 
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Loads the offset of the called procedure in the EIP register. 
Begins execution of the called procedure. 


When executing a near return, the processor performs these actions: 


1. 


Pops the top-of-stack value (the return instruction pointer) into the EIP register. 


If shadow stack is enabled, pops the top-of-stack (the return instruction pointer) value from the shadow stack 
and if it’s not the same as the return instruction pointer popped from the stack, then the processor causes a 
control protection exception with error code NEAR-RET (#CP(NEAR-RET)). 

If the RET instruction has an optional n argument, increments the stack pointer by the number of bytes 
specified with the n operand to release parameters from the stack. 


Resumes execution of the calling procedure. 


6.4.2 Far CALL and RET Operation 


When executing a far call, the processor performs these actions (see Figure 6-2): 


1. 


ou BR WN 


Pushes the current value of the CS register on the stack. 
If shadow stack is enabled: 


a. Temporarily saves the current value of the SSP register internally and aligns the SSP to the next 8 byte 
boundary. 


b. Pushes the current value of the CS register on the shadow stack. 

c. Pushes the current value of LIP (CS.base + EIP) on the shadow stack. 

d. Pushes the internally saved value of the SSP register on the shadow stack. 

Pushes the current value of the EIP register on the stack. 

Loads the segment selector of the segment that contains the called procedure in the CS register. 
Loads the offset of the called procedure in the EIP register. 

Begins execution of the called procedure. 


When executing a far return, the processor does the following: 


1. 
2. 


Pops the top-of-stack value (the return instruction pointer) into the EIP register. 

Pops the top-of-stack value (the segment selector for the code segment being returned to) into the CS register. 
If shadow stack is enabled: 

a. Causes a control protection exception (#CP(FAR-RET/IRET)) if the SSP is not aligned to 8 bytes. 


b. Compares the values on the shadow stack at address SSP+8 (the LIP) and SSP+16 (the CS) to the CS and 
(CS.base + EIP) popped from the stack, and causes a control protection exception (#CP(FAR-RET/IRET)) if 
they do not match. 


c. Pops the top-of-stack value (the SSP of the procedure being returned to) from shadow stack into the SSP 
register. 


If the RET instruction has an optional n argument, increments the stack pointer by the number of bytes 
specified with the n operand to release parameters from the stack. 


Resumes execution of the calling procedure. 
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Figure 6-2. Stack on Near and Far Calls 
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6.4.3 Parameter Passing 


Parameters can be passed between procedures in any of three ways: through general-purpose registers, in an 
argument list, or on the stack. 


6.4.3.1 Passing Parameters Through the General-Purpose Registers 


The processor does not save the state of the general-purpose registers on procedure calls. A calling procedure can 
thus pass up to six parameters to the called procedure by copying the parameters into any of these registers 
(except the ESP and EBP registers) prior to executing the CALL instruction. The called procedure can likewise pass 
parameters back to the calling procedure through general-purpose registers. 


6.4.3.2 Passing Parameters on the Stack 


To pass a large number of parameters to the called procedure, the parameters can be placed on the stack, in the 
stack frame for the calling procedure. Here, it is useful to use the stack-frame base pointer (in the EBP register) to 
make a frame boundary for easy access to the parameters. 


The stack can also be used to pass parameters back from the called procedure to the calling procedure. 


6.4.3.3 Passing Parameters in an Argument List 


An alternate method of passing a larger number of parameters (or a data structure) to the called procedure is to 
place the parameters in an argument list in one of the data segments in memory. A pointer to the argument list can 
then be passed to the called procedure through a general-purpose register or the stack. Parameters can also be 
passed back to the calling procedure in this same manner. 


6.4.4 Saving Procedure State Information 


The processor does not save the contents of the general-purpose registers, segment registers, or the EFLAGS 
register on a procedure call. A calling procedure should explicitly save the values in any of the general-purpose 
registers that it will need when it resumes execution after a return. These values can be saved on the stack or in 
memory in one of the data segments. 


The PUSHA and POPA instructions facilitate saving and restoring the contents of the general-purpose registers. 

PUSHA pushes the values in all the general-purpose registers on the stack in the following order: EAX, ECX, EDX, 
EBX, ESP (the value prior to executing the PUSHA instruction), EBP, ESI, and EDI. The POPA instruction pops all the 
register values saved with a PUSHA instruction (except the ESP value) from the stack to their respective registers. 


If a called procedure changes the state of any of the segment registers explicitly, it should restore them to their 
former values before executing a return to the calling procedure. 


If a calling procedure needs to maintain the state of the EFLAGS register, it can save and restore all or part of the 
register using the PUSHF/PUSHFD and POPF/POPFD instructions. The PUSHF instruction pushes the lower word of 
the EFLAGS register on the stack, while the PUSHFD instruction pushes the entire register. The POPF instruction 
pops a word from the stack into the lower word of the EFLAGS register, while the POPFD instruction pops a double 
word from the stack into the register. 


6.4.5 Calls to Other Privilege Levels 


The IA-32 architecture’s protection mechanism recognizes four privilege levels, numbered from 0 to 3, where a 
greater number mean less privilege. The reason to use privilege levels is to improve the reliability of operating 
systems. For example, Figure 6-4 shows how privilege levels can be interpreted as rings of protection. 
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Figure 6-4. Protection Rings 


In this example, the highest privilege level 0 (at the center of the diagram) is used for segments that contain the 
most critical code modules in the system, usually the kernel of an operating system. The outer rings (with progres- 
sively lower privileges) are used for segments that contain code modules for less critical software. 


Code modules in lower privilege segments can only access modules operating at higher privilege segments by 
means of a tightly controlled and protected interface called a gate. Attempts to access higher privilege segments 
without going through a protection gate and without having sufficient access rights causes a general-protection 
exception (#GP) to be generated. 


If an operating system or executive uses this multilevel protection mechanism, a call to a procedure that is ina 
more privileged protection level than the calling procedure is handled in a similar manner as a far call (see Section 
6.4.2, “Far CALL and RET Operation”). The differences are as follows: 


* The segment selector provided in the CALL instruction references a special data structure called a call gate 
descriptor. Among other things, the call gate descriptor provides the following: 


— access rights information 
— the segment selector for the code segment of the called procedure 
— an offset into the code segment (that is, the instruction pointer for the called procedure) 


¢ The processor switches to a new stack to execute the called procedure. Each privilege level has its own stack. 
The segment selector and stack pointer for the privilege level 3 stack are stored in the SS and ESP registers, 
respectively, and are automatically saved when a call to a more privileged level occurs. The segment selectors 
and stack pointers for the privilege level 2, 1, and O stacks are stored in a system segment called the task state 
segment (TSS). 


The use of a call gate and the TSS during a stack switch are transparent to the calling procedure, except when a 
general-protection exception is raised. 


6.4.6 CALL and RET Operation Between Privilege Levels 

When making a call to a more privileged protection level, the processor does the following (see Figure 6-5): 
1. Performs an access rights check (privilege check). 

2. Temporarily saves (internally) the current contents of the SS, ESP, CS, and EIP registers. 
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Figure 6-5. Stack Switch on a Call to a Different Privilege Level 
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Figure 6-6. Shadow Stack Switch on a Call to a Different Privilege Level 


called) from the TSS into the SS and ESP registers and switches to the new stack. 


4. Pushes the temporarily saved SS and ESP values for the calling procedure’s stack onto the new stack. 
Copies the parameters from the calling procedure’s stack to the new stack. A value in the call gate descriptor 


determines how many parameters to copy to the new stack. 


6. Pushes the temporarily saved CS and EIP values for the calling procedure to the new stack. 


If shadow stack is enabled at the privilege level of the calling procedure, then the processor temporarily saves 
the SSP of the calling procedure internally. If the calling procedure is at privilege level 3, the SSP of the calling 


procedure is also saved into the IA32_PL3_SSP MSR. 
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If shadow stack is enabled at the privilege level of the called procedure, then the SSP for the called procedure 
is obtained from one of the MSRs listed below, depending on the target privilege level. The SSP obtained is then 
verified to ensure it points to a valid supervisory shadow stack that is not currently active by verifying a 
supervisor shadow stack token at the address pointed to by the SSP. The operations performed to verify and 
acquire the supervisor shadow stack token by making it busy are as described in Section 18.2.3 of the Inte/® 
64 and IA-32 Architectures Software Developer’s Manual, Volume 1. 


— IA32_PL2_SSP if transitioning to ring 2. 
— IA32_PL1_SSP if transitioning to ring 1. 
— IA32_PLO_SSP if transitioning to ring 0. 


If shadow stack is enabled at the privilege level of the called procedure and the calling procedure was not at 
privilege level 3, then the processor pushes the temporarily saved CS, LIP (CS.base + EIP), and SSP of the 
calling procedure to the new shadow stack. 


Loads the segment selector for the new code segment and the new instruction pointer from the call gate into 
the CS and EIP registers, respectively. 


Begins execution of the called procedure at the new privilege level. 


When executing a return from the privileged procedure, the processor performs these actions: 


1. 
2. 


6. 


Performs a privilege check. 

Restores the CS and EIP registers to their values prior to the call. 

If shadow stack is enabled at the current privilege level: 

— Causes a control protection exception (#CP(FAR-RET/IRET)) if SSP is not aligned to 8 bytes. 

— Ifthe privilege level of the procedure being returned to is less than 3 (returning to supervisor mode): 


* Compares the values on shadow stack at address SSP+8 (the LIP) and SSP+16 (the CS) to the CS and 
(CS.base + EIP) popped from the stack and causes a control protection exception (#CP(FAR- 
RET/IRET)) if they do not match. 


¢ Temporarily saves the top-of-stack value (the SSP of the procedure being returned to) internally. 


— Ifa busy supervisor shadow stack token is present at address SSP+24, then marks the token free using 
operations described in Section 18.2.3 of the Inte/® 64 and IA-32 Architectures Software Developer’s 
Manual, Volume 1. 


— Ifthe privilege level of the procedure being returned to is less than 3 (returning to supervisor mode), re- 
stores the SSP register from the internally saved value. 


— Ifthe privilege level of the procedure being returned to is 3 (returning to user mode) and shadow stack is 
enabled at privilege level 3, then restores the SSP register with value of IA32_PL3_SSP MSR. 


If the RET instruction has an optional n argument, increments the stack pointer by the number of bytes 
specified with the n operand to release parameters from the stack. If the call gate descriptor specifies that one 
or more parameters be copied from one stack to the other, a RET rn instruction must be used to release the 
parameters from both stacks. Here, the n operand specifies the number of bytes occupied on each stack by the 
parameters. On a return, the processor increments ESP by n for each stack to step over (effectively remove) 
these parameters from the stacks. 


Restores the SS and ESP registers to their values prior to the call, which causes a switch back to the stack of 
the calling procedure. 


If the RET instruction has an optional n argument, increments the stack pointer by the number of bytes 
specified with the n operand to release parameters from the stack (see explanation in step 3). 


Resumes execution of the calling procedure. 


See Chapter 5, “Protection,” in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, for 
detailed information on calls to privileged levels and the call gate descriptor. 
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6.4.7 Branch Functions in 64-Bit Mode 


The 64-bit extensions expand branching mechanisms to accommodate branches in 64-bit linear-address space. 
These are: 


¢ Near-branch semantics are redefined in 64-bit mode 
°* In 64-bit mode and compatibility mode, 64-bit call-gate descriptors for far calls are available 


In 64-bit mode, the operand size for all near branches (CALL, RET, JCC, JCXZ, JMP, and LOOP) is forced to 64 bits. 
These instructions update the 64-bit RIP without the need for a REX operand-size prefix. 


The following aspects of near branches are controlled by the effective operand size: 
* Truncation of the size of the instruction pointer 

° Size of a stack pop or push, due to a CALL or RET 

° Size of a stack-pointer increment or decrement, due to a CALL or RET 

¢  Indirect-branch operand size 


In 64-bit mode, all of the above actions are forced to 64 bits regardless of operand size prefixes (operand size 
prefixes are silently ignored). However, the displacement field for relative branches is still limited to 32 bits and the 
address size for near branches is not forced in 64-bit mode. 


Address sizes affect the size of RCX used for JCXZ and LOOP; they also impact the address calculation for memory 
indirect branches. Such addresses are 64 bits by default; but they can be overridden to 32 bits by an address size 
prefix. 


Software typically uses far branches to change privilege levels. The legacy IA-32 architecture provides the call-gate 
mechanism to allow software to branch from one privilege level to another, although call gates can also be used for 
branches that do not change privilege levels. When call gates are used, the selector portion of the direct or indirect 
pointer references a gate descriptor (the offset in the instruction is ignored). The offset to the destination’s code 
segment is taken from the call-gate descriptor. 


64-bit mode redefines the type value of a 32-bit call-gate descriptor type to a 64-bit call gate descriptor and 
expands the size of the 64-bit descriptor to hold a 64-bit offset. The 64-bit mode call-gate descriptor allows far 
branches that reference any location in the supported linear-address space. These call gates also hold the target 
code selector (CS), allowing changes to privilege level and default size as a result of the gate transition. 


Because immediates are generally specified up to 32 bits, the only way to specify a full 64-bit absolute RIP in 64- 
bit mode is with an indirect branch. For this reason, direct far branches are eliminated from the instruction set in 
64-bit mode. 


64-bit mode also expands the semantics of the SYSENTER and SYSEXIT instructions so that the instructions 
operate within a 64-bit memory space. The mode also introduces two new instructions: SYSCALL and SYSRET 
(which are valid only in 64-bit mode). For details, see “SYSENTER—Fast System Call,” “SYSEXIT—Fast Return from 
Fast System Call,” “SYSCALL—Fast System Call,” and “SYSRET—Return From Fast System Call” in Chapter 4, 
“Instruction Set Reference, M-U,” of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 
2B. 


6.5 INTERRUPTS AND EXCEPTIONS 


The processor provides two mechanisms for interrupting program execution, interrupts and exceptions: 
¢ Aninterrupt is an asynchronous event that is typically triggered by an I/O device. 


e An exception is a synchronous event that is generated when the processor detects one or more predefined 
conditions while executing an instruction. The IA-32 architecture specifies three classes of exceptions: faults, 
traps, and aborts. 


The processor responds to interrupts and exceptions in essentially the same way. When an interrupt or exception 
is signaled, the processor halts execution of the current program or task and switches to a handler procedure that 
has been written specifically to handle the interrupt or exception condition. The processor accesses the handler 
procedure through an entry in the interrupt descriptor table (IDT). When the handler has completed handling the 
interrupt or exception, program control is returned to the interrupted program or task. 
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The operating system, executive, and/or device drivers normally handle interrupts and exceptions independently 
from application programs or tasks. Application programs can, however, access the interrupt and exception 
handlers incorporated in an operating system or executive through assembly-language calls. The remainder of this 
section gives a brief overview of the processor’s interrupt and exception handling mechanism. See Chapter 6, 
“Interrupt and Exception Handling,” in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 
3A, for a description of this mechanism. 


The IA-32 Architecture defines 18 predefined interrupts and exceptions and 224 user defined interrupts, which are 
associated with entries in the IDT. Each interrupt and exception in the IDT is identified with a number, called a 
vector. Table 6-1 lists the interrupts and exceptions with entries in the IDT and their respective vectors. Vectors 0 
through 8, 10 through 14, and 16 through 19 are the predefined interrupts and exceptions; vectors 32 through 255 
are for software-defined interrupts, which are for either software interrupts or maskable hardware inter- 
rupts. 


Note that the processor defines several additional interrupts that do not point to entries in the IDT; the most 
notable of these interrupts is the SMI interrupt. See Chapter 6, “Interrupt and Exception Handling,” in the Inte/® 
64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, for more information about the interrupts 
and exceptions. 


When the processor detects an interrupt or exception, it does one of the following things: 
¢ Executes an implicit call to a handler procedure. 
¢ Executes an implicit call to a handler task. 


6.5.1 Call and Return Operation for Interrupt or Exception Handling Procedures 


A call to an interrupt or exception handler procedure is similar to a procedure call to another protection level (see 
Section 6.4.6, “CALL and RET Operation Between Privilege Levels”). Here, the vector references one of two kinds 
of gates in the IDT: an interrupt gate or a trap gate. Interrupt and trap gates are similar to call gates in that they 
provide the following information: 


¢ Access rights information 
¢ The segment selector for the code segment that contains the handler procedure 
¢ An offset into the code segment to the first instruction of the handler procedure 


The difference between an interrupt gate and a trap gate is as follows. If an interrupt or exception handler is called 
through an interrupt gate, the processor clears the interrupt enable (IF) flag in the EFLAGS register to prevent 
subsequent interrupts from interfering with the execution of the handler. When a handler is called through a trap 
gate, the state of the IF flag is not changed. 


Table 6-1. Exceptions and Interrupts 


Vector | Mnemonic Description Source 
0 #DE Divide Error DIV and IDIV instructions. 
#DB Debug Any code or data reference. 

2 NMI Interrupt Non-maskable external interrupt. 

3 #BP Breakpoint INT3 instruction. 

4 #OF Overflow INTO instruction. 

5 #BR BOUND Range Exceeded BOUND instruction. 

ts) #UD Invalid Opcode (Undefined Opcode) UD instruction or reserved opcode. 

7 #NM Device Not Available (No Math Coprocessor) Floating-point or WAIT/FWAIT instruction. 

8 #DF Double Fault Any instruction that can generate an exception, an NMI, or 

an INTR. 

9 #MF CoProcessor Segment Overrun (reserved) Floating-point instruction.' 
10 #TS Invalid TSS Task switch or TSS access. 
11 #NP Segment Not Present Loading segment registers or accessing system segments. 
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Table 6-1. Exceptions and Interrupts (Contd.) 


Vector | Mnemonic Description Source 
12 #SS Stack Segment Fault Stack operations and SS register loads. 
13 #GP General Protection Any memory reference and other protection checks. 
14 HPF Page Fault Any memory reference. 
15 Reserved 
16 #MF Floating-Point Error (Math Fault) Floating-point or WAIT/FWAIT instruction. 
17 #AC Alignment Check Any data reference in memory.2 
18 #MC Machine Check Error codes (if any) and source are model dependent. 
19 #XM SIMD Floating-Point Exception SIMD Floating-Point Instruction* 
20 #VE Virtualization Exception EPT violations? 
21 #CP Control Protection Exception The RET, IRET, RSTORSSP, and SETSSBSY instructions can 
generate this exception. When CET indirect branch tracking 
is enabled, this exception can be generated due to a 
missing ENDBRANCH instruction at the target of an indirect 
call or jump. 
22-31 Reserved 
32-255 Maskable Interrupts External interrupt from INTR pin or INT n instruction. 
NOTES: 


1. IA-32 processors after the Intel386 processor do not generate this exception. 


2. This exception was introduced in the Intel486 processor. 


3. This exception was introduced in the Pentium processor and enhanced in the P6 family processors. 


4. This exception was introduced in the Pentium Ill processor. 


5. This exception can occur only on processors that support the 1-setting of the “EPT-violation #VE” VM-execution control. 


If the code segment for the handler procedure has the same privilege level as the currently executing program or 
task, the handler procedure uses the current stack; if the handler executes at a more privileged level, the processor 
switches to the stack for the handler’s privilege level. 


If no stack switch occurs, the processor does the following when calling an interrupt or exception handler (see 
Figure 6-7): 


1. Pushes the current contents of the EFLAGS, CS, and EIP registers (in that order) on the stack. 
If shadow stack is enabled: 
a. Temporarily saves the current value of the SSP register internally. 
b. Pushes the current value of the CS register on the shadow stack. 
c. Pushes the current value of LIP (CS.base + EIP) on the shadow stack. 
d. Pushes the temporarily saved SSP value on the shadow stack. 
Pushes an error code (if appropriate) on the stack. 


Loads the segment selector for the new code segment and the new instruction pointer (from the interrupt gate 
or trap gate) into the CS and EIP registers, respectively. 


If the call is through an interrupt gate, clears the IF flag in the EFLAGS register. 
Begins execution of the handler procedure. 
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Stack Usage with No Privilege-Level Change 
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Figure 6-7. Stack Usage on Transfers to Interrupt and Exception Handling Routines 
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Shadow Stack Usage with No Privilege-Level Change 
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Figure 6-8. Shadow Stack Usage on Transfers to Interrupt and Exception Handling Routines 
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If a stack switch does occur, the processor does the following: 


1. 
2. 


6. 
7. 


Temporarily saves (internally) the current contents of the SS, ESP, EFLAGS, CS, and EIP registers. 


Loads the segment selector and stack pointer for the new stack (that is, the stack for the privilege level being 
called) from the TSS into the SS and ESP registers and switches to the new stack. 


Pushes the temporarily saved SS, ESP, EFLAGS, CS, and EIP values for the interrupted procedure’s stack onto 
the new stack. 


If shadow stack is enabled at the privilege level of the interrupted procedure, then the processor temporarily 
saves the SSP of the interrupted procedure internally. If the interrupted procedure is at privilege level 3, the 
SSP of the interrupted procedure is also saved into the IA32_PL3_SSP MSR. 


If shadow stack is enabled at the privilege level being called, then the SSP for the called privilege level is 
obtained from one of the MSRs listed below, depending on the target privilege level. The SSP obtained is then 
verified to ensure it points to a valid supervisory shadow stack that is not currently active by verifying a 
supervisor shadow stack token at the address pointed to by the SSP. The operations performed to verify and 
acquire the supervisor shadow stack token by making it busy are as described in Section 18.2.3 of the Inte/® 
64 and IA-32 Architectures Software Developer’s Manual, Volume 1. 


— IA32_PL2_SSP if transitioning to ring 2. 
— IA32_PL1_SSP if transitioning to ring 1. 
— IA32_PLO_SSP if transitioning to ring 0. 


If shadow stack is enabled at the privilege level being called and the interrupted procedure was not at privilege 
level 3, then the processor pushes the temporarily saved CS, LIP (CS.base + EIP), and SSP of the interrupted 
procedure to the new shadow stack. 


Pushes an error code on the new stack (if appropriate). 


Loads the segment selector for the new code segment and the new instruction pointer (from the interrupt gate 
or trap gate) into the CS and EIP registers, respectively. 


If the call is through an interrupt gate, clears the IF flag in the EFLAGS register. 
Begins execution of the handler procedure at the new privilege level. 


A return from an interrupt or exception handler is initiated with the IRET instruction. The IRET instruction is similar 
to the far RET instruction, except that it also restores the contents of the EFLAGS register for the interrupted proce- 
dure. When executing a return from an interrupt or exception handler from the same privilege level as the inter- 
rupted procedure, the processor performs these actions: 


1. 


2. 
3. 
4. 


Restores the CS and EIP registers to their values prior to the interrupt or exception. 
If shadow stack is enabled: 


a. Compares the values on the shadow stack at address SSP+8 (the LIP) and SSP+16 (the CS) to the CS and 
(CS.base + EIP) popped from the stack, and causes a control protection exception (#CP(FAR-RET/IRET)) if 
they do not match. 


b. Pops the top-of-stack value (the SSP prior to the interrupt or exception) from the shadow stack into the SSP 
register. 


Restores the EFLAGS register. 
Increments the stack pointer appropriately. 
Resumes execution of the interrupted procedure. 


When executing a return from an interrupt or exception handler from a different privilege level than the interrupted 
procedure, the processor performs these actions: 


1. 
2. 
3. 


Performs a privilege check. 

Restores the CS and EIP registers to their values prior to the interrupt or exception. 

Restores the EFLAGS register. 

If shadow stack is enabled at the current privilege level: 

— If SSP is not aligned to 8 bytes, then causes a control protection exception (#CP(FAR-RET/IRET)). 
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If the privilege level of the procedure being returned to is less than 3 (returning to supervisor mode): 


* Compares the values on the shadow stack at address SSP+8 (the LIP) and SSP+16 (the CS) to the CS 
and (CS.base + EIP) popped from the stack, and causes a control protection exception (#CP(FAR- 
RET/IRET)) if they do not match. 


¢ Temporarily saves the top-of-stack value (the SSP of the procedure being returned to) internally. 


— Ifa busy supervisor shadow stack token is present at address SSP+24, then marks the token free using 
operations described in Section 18.2.3 of the Inte/® 64 and IA-32 Architectures Software Developer’s 
Manual, Volume 1. 


— Ifthe privilege level of the procedure being returned to is less than 3 (returning to supervisor mode), 
restores the SSP register from the internally saved value. 


— Ifthe privilege level of the procedure being returned to is 3 (returning to user mode) and shadow stack is 
enabled at privilege level 3, then restores the SSP register with the value of the IA32_PL3_SSP MSR. 


4. Restores the SS and ESP registers to their values prior to the interrupt or exception, resulting in a stack switch 
back to the stack of the interrupted procedure. 


5. Resumes execution of the interrupted procedure. 


6.5.2 Calls to Interrupt or Exception Handler Tasks 


Interrupt and exception handler routines can also be executed in a separate task. Here, an interrupt or exception 
causes a task switch to a handler task. The handler task is given its own address space and (optionally) can execute 
at a higher protection level than application programs or tasks. 


The switch to the handler task is accomplished with an implicit task call that references a task gate descriptor. 
The task gate provides access to the address space for the handler task. As part of the task switch, the processor 
saves complete state information for the interrupted program or task. Upon returning from the handler task, the 
state of the interrupted program or task is restored and execution continues. See Chapter 6, “Interrupt and Excep- 
tion Handling,” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, for more infor- 
mation on handling interrupts and exceptions through handler tasks. 


6.5.3 Interrupt and Exception Handling in Real-Address Mode 


When operating in real-address mode, the processor responds to an interrupt or exception with an implicit far call 
to an interrupt or exception handler. The processor uses the interrupt or exception vector as an index into an inter- 
rupt table. The interrupt table contains instruction pointers to the interrupt and exception handler procedures. 


The processor saves the state of the EFLAGS register, the EIP register, the CS register, and an optional error code 
on the stack before switching to the handler procedure. 


A return from the interrupt or exception handler is carried out with the IRET 
instruction. 


See Chapter 19, “8086 Emulation,” in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 
3B, for more information on handling interrupts and exceptions in real-address mode. 


6.5.4 INT n, INTO, INT3, INT1, and BOUND Instructions 


The INT n, INTO, INT3, and BOUND instructions allow a program or task to explicitly call an interrupt or exception 
handler. The INT n instruction (opcode CD) uses a vector as an argument, which allows a program to call any inter- 
rupt handler. 


The INTO instruction (opcode CE) explicitly calls the overflow exception (#OF) handler if the overflow flag (OF) in 
the EFLAGS register is set. The OF flag indicates overflow on arithmetic instructions, but it does not automatically 
raise an overflow exception. An overflow exception can only be raised explicitly in either of the following ways: 


¢ Execute the INTO instruction. 
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¢ Test the OF flag and execute the INT rn instruction with an argument of 4 (the vector of the overflow exception) 
if the flag is set. 


Both the methods of dealing with overflow conditions allow a program to test for overflow at specific places in the 
instruction stream. 

The INT3 instruction (opcode CC) explicitly calls the breakpoint exception (#BP) handler. Similarly, the INT1 
instruction (opcode F1) explicitly calls the debug exception (#DB) handler.? 


The BOUND instruction explicitly calls the BOUND-range exceeded exception (#BR) handler if an operand is found 
to be not within predefined boundaries in memory. This instruction is provided for checking references to arrays 
and other data structures. Like the overflow exception, the BOUND-range exceeded exception can only be raised 
explicitly with the BOUND instruction or the INT rn instruction with an argument of 5 (the vector of the bounds- 
check exception). The processor does not implicitly perform bounds checks and raise the BOUND-range exceeded 
exception. 


6.5.5 Handling Floating-Point Exceptions 


When operating on individual or packed floating-point values, the IA-32 architecture supports a set of six floating- 
point exceptions. These exceptions can be generated during operations performed by the x87 FPU instructions or 
by SSE/SSE2/SSE3 instructions. When an x87 FPU instruction (including the FISTTP instruction in SSE3) generates 
one or more of these exceptions, it in turn generates floating-point error exception (#MF); when an 
SSE/SSE2/SSE3 instruction generates a floating-point exception, it in turn generates SIMD floating-point excep- 
tion (#XM). 

See the following sections for further descriptions of the floating-point exceptions, how they are generated, and 
how they are handled: 


® Section 4.9.1, “Floating-Point Exception Conditions,” and Section 4.9.3, “Typical Actions of a Floating-Point 
Exception Handler” 


° Section 8.4, “x87 FPU Floating-Point Exception Handling,” and Section 8.5, “x87 FPU Floating-Point Exception 
Conditions” 


¢ Section 11.5.1, “SIMD Floating-Point Exceptions” 
¢ Interrupt Behavior 


6.5.6 Interrupt and Exception Behavior in 64-Bit Mode 


64-bit extensions expand the legacy IA-32 interrupt-processing and exception-processing mechanism to allow 
support for 64-bit operating systems and applications. Changes include: 


¢ All interrupt handlers pointed to by the IDT are 64-bit code (does not apply to the SMI handler). 
¢ The size of interrupt-stack pushes is fixed at 64 bits. The processor uses 8-byte, zero extended stores. 


¢ The stack pointer (SS:RSP) is pushed unconditionally on interrupts. In legacy environments, this push is 
conditional and based on a change in current privilege level (CPL). 


¢ The new SS is set to NULL if there is a change in CPL. 

¢ _IRET behavior changes. 

¢ There is a new interrupt stack-switch mechanism and a new interrupt shadow stack-switch mechanism. 
¢ The alignment of interrupt stack frame is different. 


1. Hardware vendors may use the INT1 instruction for hardware debug. For that reason, Intel recommends software vendors instead 
use the INT3 instruction for software breakpoints. 
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6.6 PROCEDURE CALLS FOR BLOCK-STRUCTURED LANGUAGES 


The IA-32 architecture supports an alternate method of performing procedure calls with the ENTER (enter proce- 
dure) and LEAVE (leave procedure) instructions. These instructions automatically create and release, respectively, 
stack frames for called procedures. The stack frames have predefined spaces for local variables and the necessary 
pointers to allow coherent returns from called procedures. They also allow scope rules to be implemented so that 
procedures can access their own local variables and some number of other variables located in other stack frames. 


ENTER and LEAVE offer two benefits: 
¢ They provide machine-language support for implementing block-structured languages, such as C and Pascal. 
° They simplify procedure entry and exit in compiler-generated code. 


6.6.1 ENTER Instruction 


The ENTER instruction creates a stack frame compatible with the scope rules typically used in block-structured 
languages. In block-structured languages, the scope of a procedure is the set of variables to which it has access. 
The rules for scope vary among languages. They may be based on the nesting of procedures, the division of the 
program into separately compiled files, or some other modularization scheme. 


ENTER has two operands. The first specifies the number of bytes to be reserved on the stack for dynamic storage 
for the procedure being called. Dynamic storage is the memory allocated for variables created when the procedure 
is called, also known as automatic variables. The second parameter is the lexical nesting level (from 0 to 31) of the 
procedure. The nesting level is the depth of a procedure in a hierarchy of procedure calls. The lexical level is unre- 
lated to either the protection privilege level or to the I/O privilege level of the currently running program or task. 


ENTER, in the following example, allocates 2 Kbytes of dynamic storage on the stack and sets up pointers to two 
previous stack frames in the stack frame for this procedure: 


ENTER 2048,3 


The lexical nesting level determines the number of stack frame pointers to copy into the new stack frame from the 
preceding frame. A stack frame pointer is a doubleword used to access the variables of a procedure. The set of 
stack frame pointers used by a procedure to access the variables of other procedures is called the display. The first 
doubleword in the display is a pointer to the previous stack frame. This pointer is used by a LEAVE instruction to 
undo the effect of an ENTER instruction by discarding the current stack frame. 


After the ENTER instruction creates the display for a procedure, it allocates the dynamic local variables for the 
procedure by decrementing the contents of the ESP register by the number of bytes specified in the first parameter. 
This new value in the ESP register serves as the initial top-of-stack for all PUSH and POP operations within the 
procedure. 


To allow a procedure to address its display, the ENTER instruction leaves the EBP register pointing to the first 
doubleword in the display. Because stacks grow down, this is actually the doubleword with the highest address in 
the display. Data manipulation instructions that specify the EBP register as a base register automatically address 
locations within the stack segment instead of the data segment. 


The ENTER instruction can be used in two ways: nested and non-nested. If the lexical level is 0, the non-nested 
form is used. The non-nested form pushes the contents of the EBP register on the stack, copies the contents of the 
ESP register into the EBP register, and subtracts the first operand from the contents of the ESP register to allocate 
dynamic storage. The non-nested form differs from the nested form in that no stack frame pointers are copied. The 
nested form of the ENTER instruction occurs when the second parameter (lexical level) is not zero. 


The following pseudo code shows the formal definition of the ENTER instruction. STORAGE is the number of bytes 
of dynamic storage to allocate for local variables, and LEVEL is the lexical nesting level. 
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PUSH EBP; 
FRAME_PTR := ESP; 
IF LEVEL > O 
THEN 
DO (LEVEL — 1) times 
EBP := EBP - 4; 
PUSH Pointer(EBP); (* doubleword pointed to by EBP *) 
OD; 


PUSH FRAME_PTR; 
Fl; 
EBP := FRAME_PTR; 
ESP := ESP — STORAGE; 


The main procedure (in which all other procedures are nested) operates at the highest lexical level, level 1. The 
first procedure it calls operates at the next deeper lexical level, level 2. A level 2 procedure can access the variables 
of the main program, which are at fixed locations specified by the compiler. In the case of level 1, the ENTER 
instruction allocates only the requested dynamic storage on the stack because there is no previous display to copy. 


A procedure that calls another procedure at a lower lexical level gives the called procedure access to the variables 
of the caller. The ENTER instruction provides this access by placing a pointer to the calling procedure's stack frame 
in the display. 


A procedure that calls another procedure at the same lexical level should not give access to its variables. In this 
case, the ENTER instruction copies only that part of the display from the calling procedure which refers to previ- 
ously nested procedures operating at higher lexical levels. The new stack frame does not include the pointer for 
addressing the calling procedure’s stack frame. 


The ENTER instruction treats a re-entrant procedure as a call to a procedure at the same lexical level. In this case, 
each succeeding iteration of the re-entrant procedure can address only its own variables and the variables of the 
procedures within which it is nested. A re-entrant procedure always can address its own variables; it does not 
require pointers to the stack frames of previous iterations. 


By copying only the stack frame pointers of procedures at higher lexical levels, the ENTER instruction makes 
certain that procedures access only those variables of higher lexical levels, not those at parallel lexical levels (see 
Figure 6-9). 


Main (Lexical Level 1) 


Procedure A (Lexical Level 2) 


Procedure B (Lexical Level 3) 


Procedure C (Lexical Level 3) 


Procedure D (Lexical Level 4) 


Figure 6-9. Nested Procedures 


Block-structured languages can use the lexical levels defined by ENTER to control access to the variables of nested 
procedures. In Figure 6-9, for example, if procedure A calls procedure B which, in turn, calls procedure C, then 
procedure C will have access to the variables of the MAIN procedure and procedure A, but not those of procedure 
B because they are at the same lexical level. The following definition describes the access to variables for the 
nested procedures in Figure 6-9. 


1. MAIN has variables at fixed locations. 
2. Procedure A can access only the variables of MAIN. 
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3. Procedure B can access only the variables of procedure A and MAIN. Procedure B cannot access the variables of 


procedure C or procedure D. 


4. Procedure C can access only the variables of procedure A and MAIN. Procedure C cannot access the variables of 


procedure B or procedure D. 


5. Procedure D can access the variables of procedure C, procedure A, and MAIN. Procedure D cannot access the 


variables of procedure B. 


In Figure 6-10, an ENTER instruction at the beginning of the MAIN procedure creates three doublewords of dynamic 
storage for MAIN, but copies no pointers from other stack frames. The first doubleword in the display holds a copy 
of the last value in the EBP register before the ENTER instruction was executed. The second doubleword holds a 
copy of the contents of the EBP register following the ENTER instruction. After the instruction is executed, the EBP 
register points to the first doubleword pushed on the stack, and the ESP register points to the last doubleword in 
the stack frame. 


When MAIN calls procedure A, the ENTER instruction creates a new display (see Figure 6-11). The first doubleword 
is the last value held in MAIN's EBP register. The second doubleword is a pointer to MAIN's stack frame which is 
copied from the second doubleword in MAIN's display. This happens to be another copy of the last value held in 


MAIN’s EBP register. Procedure A can access variables in MAIN because MAIN is at level 1. 


Therefore the base address for the dynamic storage used in MAIN is the current address in the EBP register, plus 
four bytes to account for the saved contents of MAIN’s EBP register. All dynamic variables for MAIN are at fixed, 


positive offsets from this value. 
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Figure 6-10. Stack Frame After Entering the MAIN Procedure 
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Figure 6-11. Stack Frame After Entering Procedure A 
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When procedure A calls procedure B, the ENTER instruction creates a new display (see Figure 6-12). The first 
doubleword holds a copy of the last value in procedure A’s EBP register. The second and third doublewords are 
copies of the two stack frame pointers in procedure A’s display. Procedure B can access variables in procedure A 
and MAIN by using the stack frame pointers in its display. 


When procedure B calls procedure C, the ENTER instruction creates a new display for procedure C (see 

Figure 6-13). The first doubleword holds a copy of the last value in procedure B’s EBP register. This is used by the 
LEAVE instruction to restore procedure B’s stack frame. The second and third doublewords are copies of the two 
stack frame pointers in procedure A's display. If procedure C were at the next deeper lexical level from procedure 
B, a fourth doubleword would be copied, which would be the stack frame pointer to procedure B’s local variables. 


Note that procedure B and procedure C are at the same level, so procedure C is not intended to access procedure 
B’s variables. This does not mean that procedure C is completely isolated from procedure B; procedure C is called 
by procedure B, so the pointer to the returning stack frame is a pointer to procedure B’s stack frame. In addition, 
procedure B can pass parameters to procedure C either on the stack or through variables global to both procedures 
(that is, variables in the scope of both procedures). 
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Figure 6-12. Stack Frame After Entering Procedure B 
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Figure 6-13. Stack Frame After Entering Procedure C 


6.6.2 LEAVE Instruction 


The LEAVE instruction, which does not have any operands, reverses the action of the previous ENTER instruction. 
The LEAVE instruction copies the contents of the EBP register into the ESP register to release all stack space allo- 
cated to the procedure. Then it restores the old value of the EBP register from the stack. This simultaneously 
restores the ESP register to its original value. A subsequent RET instruction then can remove any arguments and 
the return address pushed on the stack by the calling program for use by the procedure. 
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CHAPTER 7 
PROGRAMMING WITH 
GENERAL-PURPOSE INSTRUCTIONS 


General-purpose (GP) instructions are a subset of the IA-32 instructions that represent the fundamental instruction 
set for the Intel IA-32 processors. These instructions were introduced into the IA-32 architecture with the first IA- 
32 processors (the Intel 8086 and 8088). Additional instructions were added to the general-purpose instruction set 
in subsequent families of IA-32 processors (the Intel 286, Intel386, Intel486, Pentium, Pentium Pro, and Pentium 
II processors). 


Intel 64 architecture further extends the capability of most general-purpose instructions so that they are able to 
handle 64-bit data in 64-bit mode. A small number of general-purpose instructions (still supported in non-64-bit 
modes) are not supported in 64-bit mode. 


General-purpose instructions perform basic data movement, memory addressing, arithmetic and logical, program 
flow control, input/output, and string operations on a set of integer, pointer, and BCD data types. This chapter 
provides an overview of the general-purpose instructions. See Intel® 64 and IA-32 Architectures Software Devel- 
oper’s Manual, Volumes 2A, 2B, 2C & 2D, for detailed descriptions of individual instructions. 


7.1 PROGRAMMING ENVIRONMENT FOR GP INSTRUCTIONS 


The programming environment for the general-purpose instructions consists of the set of registers and address 
space. The environment includes the following items: 


¢ General-purpose registers — Eight 32-bit general-purpose registers (see Section 3.4.1, “General-Purpose 
Registers”) are used in non-64-bit modes to address operands in memory. These registers are referenced by 
the names EAX, EBX, ECX, EDX, EBP, ESI EDI, and ESP. 


¢ Segment registers — The six 16-bit segment registers contain segment pointers for use in accessing memory 
(see Section 3.4.2, “Segment Registers”). These registers are referenced by the names CS, DS, SS, ES, FS, and 
GS. 


¢ EFLAGS register — This 32-bit register (see Section 3.4.3, “EFLAGS Register”) is used to provide status and 
control for basic arithmetic, compare, and system operations. 


¢ EIP register — This 32-bit register contains the current instruction pointer (see Section 3.5, “Instruction 
Pointer”). 


General-purpose instructions operate on the following data types. The width of valid data types is dependent on 
processor mode (see Chapter 4): 


¢ Bytes, words, doublewords 

¢ Signed and unsigned byte, word, doubleword integers 
¢ Near and far pointers 

° Bit fields 

° BCD integers 


7.2 PROGRAMMING ENVIRONMENT FOR GP INSTRUCTIONS IN 64-BIT MODE 


The programming environment for the general-purpose instructions in 64-bit mode is similar to that described in 
Section 7.1. 


¢ General-purpose registers — In 64-bit mode, sixteen general-purpose registers available. These include the 
eight GPRs described in Section 7.1 and eight new GPRs (R8D-R1i5D). R8D-R15D are available by using a REX 
prefix. All sixteen GPRs can be promoted to 64 bits. The 64-bit registers are referenced as RAX, RBX, RCX, RDX, 
RBP, RSI, RDI, RSP and R8-R15 (see Section 3.4.1.1, “General-Purpose Registers in 64-Bit Mode”). Promotion 
to 64-bit operand requires REX prefix encodings. 
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¢ Segment registers — In 64-bit mode, segmentation is available but it is set up uniquely (see Section 3.4.2.1, 
“Segment Registers in 64-Bit Mode”). 


¢ Flags and Status register — When the processor is running in 64-bit mode, EFLAGS becomes the 64-bit 
RFLAGS register (see Section 3.4.3, “EFLAGS Register”). 


* Instruction Pointer register — In 64-bit mode, the EIP register becomes the 64-bit RIP register (see Section 
3.5.1, “Instruction Pointer in 64-Bit Mode”). 


General-purpose instructions operate on the following data types in 64-bit mode. The width of valid data types is 
dependent on default operand size, address size, or a prefix that overrides the default size: 


¢ Bytes, words, doublewords, quadwords 

® Signed and unsigned byte, word, doubleword, quadword integers 

¢ Near and far pointers 

° Bit fields 

See also: 

° Chapter 3, “Basic Execution Environment,” for more information about IA-32e modes. 


® Chapter 2, “Instruction Format,” in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 2A, for more detailed information about REX prefixes. 


° Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A & 2B for a complete listing of all 
instructions. This information documents the behavior of individual instructions in the 64-bit mode context. 


7.3 SUMMARY OF GP INSTRUCTIONS 


General purpose instructions are divided into the following subgroups: 
° Data transfer 

¢ Binary arithmetic 
* Decimal arithmetic 
* Logical 

¢ = Shift and rotate 

° Bit and byte 

* Control transfer 

° String 

¢ 1/0 

e Enter and Leave 

° Flag control 

° Segment register 
¢ Miscellaneous 


Each sub-group of general-purpose instructions is discussed in the context of non-64-bit mode operation first. 
Changes in 64-bit mode beyond those affected by the use of the REX prefixes are discussed in separate sub- 
sections within each subgroup. For a simple list of general-purpose instructions by subgroup, see Chapter 5. 


7.3.1 Data Transfer Instructions 


The data transfer instructions move bytes, words, doublewords, or quadwords both between memory and the 
processor’s registers and between registers. For the purpose of this discussion, these instructions are divided into 
subordinate subgroups that provide for: 


© General data movement 
° Exchange 
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¢ Stack manipulation 
¢ ~=Type conversion 


7.3.1.1 General Data Movement Instructions 


Move instructions — The MOV (move) and CMOVcc (conditional move) instructions transfer data between 
memory and registers or between registers. 


The MOV instruction performs basic load data and store data operations between memory and the processor’s 
registers and data movement operations between registers. It handles data transfers along the paths listed in Table 
7-1. (See “MOV—Move to/from Control Registers” and “MOV—Move to/from Debug Registers” in Chapter 4, 
“Instruction Set Reference, M-U,” of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 
2A, for information on moving data to and from the control and debug registers.) 


The MOV instruction cannot move data from one memory location to another or from one segment register to 
another segment register. Memory-to-memory moves are performed with the MOVS (string move) instruction (see 
Section 7.3.9, “String Operations”). 


Conditional move instructions — The CMOVcc instructions are a group of instructions that check the state of the 
status flags in the EFLAGS register and perform a move operation if the flags are in a specified state. These instruc- 
tions can be used to move a 16-bit or 32-bit value from memory to a general-purpose register or from one general- 
purpose register to another. The flag state being tested is specified with a condition code (cc) associated with the 

instruction. If the condition is not satisfied, a move is not performed and execution continues with the instruction 

following the CMOVcc instruction. 


Table 7-1. Move Instruction Operations 
Type of Data Movement Source > Destination 


From memory to a register Memory location — General-purpose register 
Memory location — Segment register 


From a register to memory General-purpose register + Memory location 
Segment register — Memory location 


Between registers General-purpose register — General-purpose register 
General-purpose register + Segment register 
Segment register — General-purpose register 
General-purpose register — Control register 

Control register — General-purpose register 
General-purpose register — Debug register 

Debug register — General-purpose register 


Immediate data to a register Immediate > General-purpose register 


Immediate data to memory Immediate + Memory location 


Table 7-2 shows mnemonics for CMOVcc instructions and the conditions being tested for each instruction. The 
condition code mnemonics are appended to the letters “CMOV” to form the mnemonics for CMOVcc instructions. 
The instructions listed in Table 7-2 as pairs (for example, CMOVA/CMOVNBE) are alternate names for the same 
instruction. The assembler provides these alternate names to make it easier to read program listings. 


CMOVcc instructions are useful for optimizing small IF constructions. They also help eliminate branching overhead 
for IF statements and the possibility of branch mispredictions by the processor. 


These conditional move instructions are supported in the P6 family, Pentium 4, and Intel Xeon processors. Software 
can check if CMOVcc instructions are supported by checking the processor’s feature information with the CPUID 
instruction. 
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i212 Exchange Instructions 


The exchange instructions swap the contents of one or more operands and, in some cases, perform additional oper- 
ations such as asserting the LOCK signal or modifying flags in the EFLAGS register. 


The XCHG (exchange) instruction swaps the contents of two operands. This instruction takes the place of three 
MOV instructions and does not require a temporary location to save the contents of one operand location while the 
other is being loaded. When a memory operand is used with the XCHG instruction, the processor’s LOCK signal is 
automatically asserted. This instruction is thus useful for implementing semaphores or similar data structures for 
process synchronization. See “Bus Locking” in Chapter 8, “Multiple-Processor Management,”of the Inte/® 64 and 
IA-32 Architectures Software Developer’s Manual, Volume 3A, for more information on bus locking. 


The BSWAP (byte swap) instruction reverses the byte order in a 32-bit register operand. Bit positions 0 through 7 
are exchanged with 24 through 31, and bit positions 8 through 15 are exchanged with 16 through 23. Executing 
this instruction twice in a row leaves the register with the same value as before. The BSWAP instruction is useful for 
converting between “big-endian” and “little-endian” data formats. This instruction also speeds execution of decimal 
arithmetic. (The XCHG instruction can be used to swap the bytes in a word.) 


Table 7-2. Conditional Move Instructions 
Status Flag States 


Instruction Mnemonic Condition Description 


Unsigned Conditional Moves 


CMOVA/CMOVNBE (CF or ZF) = 0 Above/not below or equal 

CMOVAE/CMOVNB CF=0 Above or equal/not below 

CMOVNC CF=0 Not carry 

CMOVB/CMOVNAE CF=1 Below/not above or equal 

CMOVC CF=1 Carry 

CMOVBE/CMOVNA (CF or ZF) = 1 Below or equal/not above 

CMOVE/CMOVZ ZF=1 Equal/zero 

CMOVNE/CMOVNZ ZF=0 Not equal/not zero 

CMOVP/CMOVPE PF=1 Parity/parity even 

CMOVNP/CMOVPO PF=0 Not parity/parity odd 
Signed Conditional Moves 

CMOVGE/CMOVNL (SF xor OF) = 0 Greater or equal/not less 

CMOVL/CMOVNGE (SF xor OF) = 1 Less/not greater or equal 

CMOVLE/CMOVNG ((SF xor OF) or ZF) = 1 Less or equal/not greater 

CMOVO OF =1 Overflow 

CMOVNO OF =0 Not overflow 

CMOVS SF =1 Sign (negative) 

CMOVNS SF =0 Not sign (non-negative) 


The XADD (exchange and add) instruction swaps two operands and then stores the sum of the two operands in the 
destination operand. The status flags in the EFLAGS register indicate the result of the addition. This instruction can 
be combined with the LOCK prefix (see “LOCK—Assert LOCK# Signal Prefix” in Chapter 3, “Instruction Set Refer- 
ence, A-L,” of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A) in a multiprocessing 
system to allow multiple processors to execute one DO loop. 


The CMPXCHG (compare and exchange) and CMPXCHG8B (compare and exchange 8 bytes) instructions are used 
to synchronize operations in systems that use multiple processors. The CMPXCHG instruction requires three oper- 
ands: a source operand in a register, another source operand in the EAX register, and a destination operand. If 
the values contained in the destination operand and the EAX register are equal, the destination operand is 
replaced with the value of the other source operand (the value not in the EAX register). Otherwise, the original 
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value of the destination operand is loaded in the EAX register. The status flags in the EFLAGS register reflect the 
result that would have been obtained by subtracting the destination operand from the value in the EAX register. 


The CMPXCHG instruction is commonly used for testing and modifying semaphores. It checks to see if a semaphore 
is free. If the semaphore is free, it is marked allocated; otherwise it gets the ID of the current owner. This is all done 
in one uninterruptible operation. In a single-processor system, the CMPXCHG instruction eliminates the need to 
switch to protection level 0 (to disable interrupts) before executing multiple instructions to test and modify a sema- 
phore. 


For multiple processor systems, CMPXCHG can be combined with the LOCK prefix to perform the compare and 
exchange operation atomically. (See “Locked Atomic Operations” in Chapter 8, “Multiple-Processor Management,” 
of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, for more information on atomic 
operations. ) 


The CMPXCHG8B instruction also requires three operands: a 64-bit value in EDX:EAX, a 64-bit value in ECX:EBX, 
and a destination operand in memory. The instruction compares the 64-bit value in the EDX:EAX registers with the 
destination operand. If they are equal, the 64-bit value in the ECX:EBX registers is stored in the destination 
operand. If the EDX:EAX registers and the destination are not equal, the destination is loaded in the EDX:EAX 
registers. The CMPXCHG8B instruction can be combined with the LOCK prefix to perform the operation atomically. 


7.3.1.3 Exchange Instructions in 64-Bit Mode 


The CMPXCHG16B instruction is available in 64-bit mode only. It is an extension of the functionality provided by 
CMPXCHG8B that operates on 128-bits of data. 


7.3.1.4 Stack Manipulation Instructions 


The PUSH, POP, PUSHA (push all registers), and POPA (pop all registers) instructions move data to and from the 
stack. The PUSH instruction decrements the stack pointer (contained in the ESP register), then copies the source 
operand to the top of stack (see Figure 7-1). It operates on memory operands, immediate operands, and register 
operands (including segment registers). The PUSH instruction is commonly used to place parameters on the stack 
before calling a procedure. It can also be used to reserve space on the stack for temporary variables. 


Stack 
Before Pushing Doubleword After Pushing Doubleword 
Growth 31 0 31 0 
| ~<-ESP 
n-4 Doubleword Value |««-ESP 


Figure 7-1. Operation of the PUSH Instruction 


The PUSHA instruction saves the contents of the eight general-purpose registers on the stack (see Figure 7-2). 
This instruction simplifies procedure calls by reducing the number of instructions required to save the contents of 
the general-purpose registers. The registers are pushed on the stack in the following order: EAX, ECX, EDX, EBX, 
the initial value of ESP before EAX was pushed, EBP, ESI, and EDI. 
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Stack 
eck Before Pushing Registers After Pushing Registers 
Pos 31 0 31 0 
n 
n-4 ~<-ESP 
n-8 EAX 
n-12 ECX 
n-16 EDX 
n- 20 EBX 
n- 24 Old ESP 
n- 28 EBP 
n- 32 ESI 
n- 36 EDI ~x-ESP 


Figure 7-2. Operation of the PUSHA Instruction 


The POP instruction copies the word or doubleword at the current top of stack (indicated by the ESP register) to the 
location specified with the destination operand. It then increments the ESP register to point to the new top of stack 
(see Figure 7-3). The destination operand may specify a general-purpose register, a segment register, or a memory 
location. 


Stack 
Before Popping Doubleword After Popping Doubleword 
aoe at 0 31 0 
n 
| n-4 ~<ESP 
n-8 Doubleword Value ~x-ESP 


Figure 7-3. Operation of the POP Instruction 


The POPA instruction reverses the effect of the PUSHA instruction. It pops the top eight words or doublewords from 
the top of the stack into the general-purpose registers, except for the ESP register (see Figure 7-4). If the operand- 
size attribute is 32, the doublewords on the stack are transferred to the registers in the following order: EDI, ESI, 
EBP, ignore doubleword, EBX, EDX, ECX, and EAX. The ESP register is restored by the action of popping the stack. 
If the operand-size attribute is 16, the words on the stack are transferred to the registers in the following order: DI, 
SI, BP, ignore word, BX, DX, CX, and AX. 
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Stack 
Before Popping Registers After Popping Registers 
Stack 0 31 0 31 
Growth 

n-4 ~x-ESP 

n-8 EAX 
n-12 ECX 
n-16 EDX 
n-20 EBX 
n-24 Ignored 
n- 28 EBP 
n- 32 ESI 
n- 36 EDI ~«-ESP 


Figure 7-4. Operation of the POPA Instruction 


7.3.1.5 Stack Manipulation Instructions in 64-Bit Mode 


In 64-bit mode, the stack pointer size is 64 bits and cannot be overridden by an instruction prefix. In implicit stack 
references, address-size overrides are ignored. Pushes and pops of 32-bit values on the stack are not possible in 
64-bit mode. 16-bit pushes and pops are supported by using the 66H operand-size prefix. PUSHA, PUSHAD, POPA, 
and POPAD are not supported. 


7.3.1.6 Type Conversion Instructions 


The type conversion instructions convert bytes into words, words into doublewords, and doublewords into quad- 
words. These instructions are especially useful for converting integers to larger integer formats, because they 
perform sign extension (see Figure 7-5). 


Two kinds of type conversion instructions are provided: simple conversion and move and convert. 


15 0 
Ss NINNIN/NIN NIN/N/NININ NINiN} Before Sign 
Extension 

31 15 0 
sisis/sisisis/sisisisisis/sis/sis/NIN/ININNIN/NININININININ/N{N| Aer Sign 
Extension 


Figure 7-5. Sign Extension 


Simple conversion — The CBW (convert byte to word), CWDE (convert word to doubleword extended), CWD 
(convert word to doubleword), and CDQ (convert doubleword to quadword) instructions perform sign extension to 
double the size of the source operand. 


The CBW instruction copies the sign (bit 7) of the byte in the AL register into every bit position of the upper byte of 
the AX register. The CWDE instruction copies the sign (bit 15) of the word in the AX register into every bit position 
of the high word of the EAX register. 


The CWD instruction copies the sign (bit 15) of the word in the AX register into every bit position in the DX register. 
The CDQ instruction copies the sign (bit 31) of the doubleword in the EAX register into every bit position in the EDX 
register. The CWD instruction can be used to produce a doubleword dividend from a word before a word division, 

and the CDQ instruction can be used to produce a quadword dividend from a doubleword before doubleword divi- 
sion. 
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Move with sign or zero extension — The MOVSX (move with sign extension) and MOVZX (move with zero 
extension) instructions move the source operand into a register then perform the sign extension. 


The MOVSX instruction extends an 8-bit value to a 16-bit value or an 8-bit or 16-bit value to a 32-bit value by sign 
extending the source operand, as shown in Figure 7-5. The MOVZX instruction extends an 8-bit value to a 16-bit 
value or an 8-bit or 16-bit value to a 32-bit value by zero extending the source operand. 


7.3.1.7 Type Conversion Instructions in 64-Bit Mode 


The MOVSXD instruction operates on 64-bit data. It sign-extends a 32-bit value to 64 bits. This instruction is not 
encodable in non-64-bit modes. 


7.3.2 Binary Arithmetic Instructions 


Binary arithmetic instructions operate on 8-, 16-, and 32-bit numeric data encoded as signed or unsigned binary 
integers. The binary arithmetic instructions may also be used in algorithms that operate on decimal (BCD) values. 


For the purpose of this discussion, these instructions are divided into subordinate subgroups of instructions that: 
¢ Add and subtract 

¢ Increment and decrement 

® Compare and change signs 

¢ Multiply and divide 


7.3.2.1 Addition and Subtraction Instructions 


The ADD (add integers), ADC (add integers with carry), SUB (subtract integers), and SBB (subtract integers with 
borrow) instructions perform addition and subtraction operations on signed or unsigned integer operands. 


The ADD instruction computes the sum of two integer operands. 


The ADC instruction computes the sum of two integer operands, plus 1 if the CF flag is set. This instruction is used 
to propagate a carry when adding numbers in stages. 


The SUB instruction computes the difference of two integer operands. 


The SBB instruction computes the difference of two integer operands, minus 1 if the CF flag is set. This instruction 
is used to propagate a borrow when subtracting numbers in stages. 


7.3.2.2 Increment and Decrement Instructions 


The INC (increment) and DEC (decrement) instructions add 1 to or subtract 1 from an unsigned integer operand, 
respectively. A primary use of these instructions is for implementing counters. 


7.3.2.3 Increment and Decrement Instructions in 64-Bit Mode 


The INC and DEC instructions are supported in 64-bit mode. However, some forms of INC and DEC (the register 
operand being encoded using register extension field in the MOD R/M byte) are not encodable in 64-bit mode 
because the opcodes are treated as REX prefixes. 


7.3.2.4 Comparison and Sign Change Instructions 


The CMP (compare) instruction computes the difference between two integer operands and updates the OF, SF, ZF, 
AF, PF, and CF flags according to the result. The source operands are not modified, nor is the result saved. The CMP 
instruction is commonly used in conjunction with a Jcc (jump) or SETcc (byte set on condition) instruction, with the 
latter instructions performing an action based on the result of a CMP instruction. 


The NEG (negate) instruction subtracts a signed integer operand from zero. The effect of the NEG instruction is to 
change the sign of a two's complement operand while keeping its magnitude. 
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13.2.5 Multiplication and Division Instructions 


The processor provides two multiply instructions, MUL (unsigned multiply) and IMUL (signed multiply), and two 
divide instructions, DIV (unsigned divide) and IDIV (signed divide). 


The MUL instruction multiplies two unsigned integer operands. The result is computed to twice the size of the 
source operands (for example, if word operands are being multiplied, the result is a doubleword). 


The IMUL instruction multiplies two signed integer operands. The result is computed to twice the size of the source 
operands; however, in some cases the result is truncated to the size of the source operands (see “IMUL—Signed 
Multiply” in Chapter 3, “Instruction Set Reference, A-L,” of the Intel® 64 and IA-32 Architectures Software Devel- 
oper’s Manual, Volume 2A). 


The DIV instruction divides one unsigned operand by another unsigned operand and returns a quotient anda 
remainder. 


The IDIV instruction is identical to the DIV instruction, except that IDIV performs a signed division. 


7.3.3 Decimal Arithmetic Instructions 


Decimal arithmetic can be performed by combining the binary arithmetic instructions ADD, SUB, MUL, and DIV 
(discussed in Section 7.3.2, “Binary Arithmetic Instructions”) with the decimal arithmetic instructions. The decimal 
arithmetic instructions are provided to carry out the following operations: 


° To adjust the results of a previous binary arithmetic operation to produce a valid BCD result. 


° To adjust the operands of a subsequent binary arithmetic operation so that the operation will produce a valid 
BCD result. 


These instructions operate on both packed and unpacked BCD values. For the purpose of this discussion, the 
decimal arithmetic instructions are divided into subordinate subgroups of instructions that provide: 


¢ Packed BCD adjustments 
¢ Unpacked BCD adjustments 


y Ae ie ma Packed BCD Adjustment Instructions 


The DAA (decimal adjust after addition) and DAS (decimal adjust after subtraction) instructions adjust the results 
of operations performed on packed BCD integers (see Section 4.7, “BCD and Packed BCD Integers”). Adding two 
packed BCD values requires two instructions: an ADD instruction followed by a DAA instruction. The ADD instruc- 
tion adds (binary addition) the two values and stores the result in the AL register. The DAA instruction then adjusts 
the value in the AL register to obtain a valid, 2-digit, packed BCD value and sets the CF flag if a decimal carry 
occurred as the result of the addition. 


Likewise, subtracting one packed BCD value from another requires a SUB instruction followed by a DAS instruction. 
The SUB instruction subtracts (binary subtraction) one BCD value from another and stores the result in the AL 
register. The DAS instruction then adjusts the value in the AL register to obtain a valid, 2-digit, packed BCD value 
and sets the CF flag if a decimal borrow occurred as the result of the subtraction. 


13.3.2 Unpacked BCD Adjustment Instructions 


The AAA (ASCII adjust after addition), AAS (ASCII adjust after subtraction), AAM (ASCII adjust after multiplica- 
tion), and AAD (ASCII adjust before division) instructions adjust the results of arithmetic operations performed 
on unpacked BCD values (see Section 4.7, “BCD and Packed BCD Integers”). All these instructions assume that 
the value to be adjusted is stored in the AL register or, in one instance, the AL and AH registers. 


The AAA instruction adjusts the contents of the AL register following the addition of two unpacked BCD values. It 
converts the binary value in the AL register into a decimal value and stores the result in the AL register in unpacked 
BCD format (the decimal number is stored in the lower 4 bits of the register and the upper 4 bits are cleared). If a 
decimal carry occurred as a result of the addition, the CF flag is set and the contents of the AH register are incre- 
mented by 1. 
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The AAS instruction adjusts the contents of the AL register following the subtraction of two unpacked BCD values. 
Here again, a binary value is converted into an unpacked BCD value. If a borrow was required to complete the 
decimal subtract, the CF flag is set and the contents of the AH register are decremented by 1. 


The AAM instruction adjusts the contents of the AL register following a multiplication of two unpacked BCD values. 
It converts the binary value in the AL register into a decimal value and stores the least significant digit of the result 
in the AL register (in unpacked BCD format) and the most significant digit, if there is one, in the AH register (also 
in unpacked BCD format). 


The AAD instruction adjusts a two-digit BCD value so that when the value is divided with the DIV instruction, a valid 
unpacked BCD result is obtained. The instruction converts the BCD value in registers AH (most significant digit) and 
AL (least significant digit) into a binary value and stores the result in register AL. When the value in AL is divided by 
an unpacked BCD value, the quotient and remainder will be automatically encoded in unpacked BCD format. 


7.3.4 Decimal Arithmetic Instructions in 64-Bit Mode 


Decimal arithmetic instructions are not supported in 64-bit mode, they are either invalid or not encodable. 


7.3.5 Logical Instructions 


The logical instructions AND, OR, XOR (exclusive or), and NOT perform the standard Boolean operations for which 
they are named. The AND, OR, and XOR instructions require two operands; the NOT instruction operates on a 
single operand. 


7.3.6 Shift and Rotate Instructions 


The shift and rotate instructions rearrange the bits within an operand. For the purpose of this discussion, these 
instructions are further divided into subordinate subgroups of instructions that: 


e = Shift bits 
* Double-shift bits (move them between operands) 
* Rotate bits 


7.3.6.1 Shift Instructions 


The SAL (shift arithmetic left), SHL (shift logical left), SAR (shift arithmetic right), SHR (shift logical right) instruc- 
tions perform an arithmetic or logical shift of the bits in a byte, word, or doubleword. 


The SAL and SHL instructions perform the same operation (see Figure 7-6). They shift the source operand left by 
from 1 to 31 bit positions. Empty bit positions are cleared. The CF flag is loaded with the last bit shifted out of the 
operand. 
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Initial State 
CF Operand 


xX 10001000100010001000100010001111 


After 1-bit SHL/SAL Instruction 


1\'™%00010001000100010001000100011110 |~<«-0O 


After 10-bit SHL/SAL Instruction 


0 m™H00100010001000100011110000000000 |j<«-0 


Figure 7-6. SHL/SAL Instruction Operation 


The SHR instruction shifts the source operand right by from 1 to 31 bit positions (see Figure 7-7). As with the 


SHL/SAL instruction, the empty bit positions are cleared and the CF flag is loaded with the last bit shifted out of the 
operand. 


Initial State Operand CF 


10001000100010001000100010001111 x 


After 1-bit SHR Instruction 
o> 01000100010001000100010001000111}>{ 14 


After 10-bit SHR Instruction 


o> 00000000001000100010001000100010;m{ 0] 


Figure 7-7. SHR Instruction Operation 


The SAR instruction shifts the source operand right by from 1 to 31 bit positions (see Figure 7-8). This instruction 
differs from the SHR instruction in that it preserves the sign of the source operand by clearing empty bit positions 


if the operand is positive or setting the empty bits if the operand is negative. Again, the CF flag is loaded with the 
last bit shifted out of the operand. 


The SAR and SHR instructions can also be used to perform division by powers of 2 (see “SAL/SAR/SHL/SHR—Shift 
Instructions” in Chapter 4, “Instruction Set Reference, M-U,” of the Inte/® 64 and IA-32 Architectures Software 
Developer’s Manual, Volume 2B). 
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Initial State (Positive Operand) Operand CF 


01000100010001000100010001000111 x 


After 1-bit SAR Instruction 


— wr}0010001000100010001000100010001 1 tr 1 


Initial State (Negative Operand) CF 


110001000100010001000100010001 11 }| X 


After 1-bit SAR Instruction 


—wre1110001000100010001000100010001 1 > 1 


Figure 7-8. SAR Instruction Operation 


7.3.6.2 Double-Shift Instructions 


The SHLD (shift left double) and SHRD (shift right double) instructions shift a specified number of bits from one 
operand to another (see Figure 7-9). They are provided to facilitate operations on unaligned bit strings. They can 
also be used to implement a variety of bit string move operations. 


SHLD Instruction 
31 0 


CF j~<«— Destination (Memory or Register) a 


31 0 


Source (Register) 


31 SHRD Instruction 0 


Source (Register) | 


31 0 
| Destination (Memory or Register) >} CF 


Figure 7-9. SHLD and SHRD Instruction Operations 


The SHLD instruction shifts the bits in the destination operand to the left and fills the empty bit positions (in the 
destination operand) with bits shifted out of the source operand. The destination and source operands must be the 
same length (either words or doublewords). The shift count can range from 0 to 31 bits. The result of this shift 
operation is stored in the destination operand, and the source operand is not modified. The CF flag is loaded with 
the last bit shifted out of the destination operand. 


The SHRD instruction operates the same as the SHLD instruction except bits are shifted to the right in the destina- 
tion operand, with the empty bit positions filled with bits shifted out of the source operand. 
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7.3.6.3 Rotate Instructions 


The ROL (rotate left), ROR (rotate right), RCL (rotate through carry left) and RCR (rotate through carry right) 
instructions rotate the bits in the destination operand out of one end and back through the other end (see 
Figure 7-10). Unlike a shift, no bits are lost during a rotation. The rotate count can range from 0 to 31. 


ROL Instruction 


31 0 
CF |j<——+ Destination (Memory or Register) <—_ 
31 ROR Instruction 0 
et Destination (Memory or Register) [7 3| CF 
31 RCL Instruction 0 


CF |~« Destination (Memory or Register) <—_ 


31 RCR Instruction 0 


=a Destination (Memory or Register) >| CF 


Figure 7-10. ROL, ROR, RCL, and RCR Instruction Operations 


The ROL instruction rotates the bits in the operand to the left (toward more significant bit locations). The ROR 
instruction rotates the operand right (toward less significant bit locations). 


The RCL instruction rotates the bits in the operand to the left, through the CF flag. This instruction treats the CF flag 
as a one-bit extension on the upper end of the operand. Each bit that exits from the most significant bit location of 
the operand moves into the CF flag. At the same time, the bit in the CF flag enters the least significant bit location 
of the operand. 


The RCR instruction rotates the bits in the operand to the right through the CF flag. 


For all the rotate instructions, the CF flag always contains the value of the last bit rotated out of the operand, even 
if the instruction does not use the CF flag as an extension of the operand. The value of this flag can then be tested 
by a conditional jump instruction (JC or JNC). 


7.3.7 Bit and Byte Instructions 


These instructions operate on bit or byte strings. For the purpose of this discussion, they are further divided into 
subordinate subgroups that: 


¢ Test and modify a single bit 

° Scan a bit string 

° Set a byte given conditions 

¢ Test operands and report results 
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7.3.7.1 Bit Test and Modify Instructions 


The bit test and modify instructions (see Table 7-3) operate on a single bit, which can be in an operand. The loca- 
tion of the bit is specified as an offset from the least significant bit of the operand. When the processor identifies 
the bit to be tested and modified, it first loads the CF flag with the current value of the bit. Then it assigns a new 
value to the selected bit, as determined by the modify operation for the instruction. 


Table 7-3. Bit Test and Modify Instructions 


Instruction Effect on CF Flag Effect on Selected Bit 

BT (Bit Test) CF flag < Selected Bit No effect 

BTS (Bit Test and Set) CF flag < Selected Bit Selected Bit < 1 

BTR (Bit Test and Reset) CF flag < Selected Bit Selected Bit < 0 

BTC (Bit Test and Complement) CF flag < Selected Bit Selected Bit — NOT (Selected Bit) 


7.3.7.2 Bit Scan Instructions 


The BSF (bit scan forward) and BSR (bit scan reverse) instructions scan a bit string in a source operand for a set bit 
and store the bit index of the first set bit found in a destination register. The bit index is the offset from the least 
significant bit (bit 0) in the bit string to the first set bit. The BSF instruction scans the source operand low-to-high 
(from bit 0 of the source operand toward the most significant bit); the BSR instruction scans high-to-low (from the 
most significant bit toward the least significant bit). 


7.3.7.3 Byte Set on Condition Instructions 


The SETcc (set byte on condition) instructions set a destination-operand byte to 0 or 1, depending on the state of 
selected status flags (CF, OF, SF, ZF, and PF) in the EFLAGS register. The suffix (cc) added to the SET mnemonic 
determines the condition being tested for. 


For example, the SETO instruction tests for overflow. If the OF flag is set, the destination byte is set to 1; if OF is 
clear, the destination byte is cleared to 0. Appendix B, “EFLAGS Condition Codes,” lists the conditions it is possible 
to test for with this instruction. 


7.3.7.4 Test Instruction 


The TEST instruction performs a logical AND of two operands and sets the SF, ZF, and PF flags according to the 
results. The flags can then be tested by the conditional jump or loop instructions or the SETcc instructions. The 
TEST instruction differs from the AND instruction in that it does not alter either of the operands. 


7.3.8 Control Transfer Instructions 


The processor provides both conditional and unconditional control transfer instructions to direct the flow of 
program execution. Conditional transfers are taken only for specified states of the status flags in the EFLAGS 
register. Unconditional control transfers are always executed. 


For the purpose of this discussion, these instructions are further divided into subordinate subgroups that process: 
¢ Unconditional transfers 

* Conditional transfers 

° Software interrupts 


7.3.8.1 Unconditional Transfer Instructions 


The JMP, CALL, RET, INT, and IRET instructions transfer program control to another location (destination address) 
in the instruction stream. The destination can be within the same code segment (near transfer) or in a different 
code segment (far transfer). 


7-14 Vol. 1 


PROGRAMMING WITH GENERAL-PURPOSE INSTRUCTIONS 


Jump instruction — The JMP (jump) instruction unconditionally transfers program control to a destination 
instruction. The transfer is one-way; that is, a return address is not saved. A destination operand specifies the 
address (the instruction pointer) of the destination instruction. The address can be a relative address or an 
absolute address. 


A relative address is a displacement (offset) with respect to the address in the EIP register. The destination 
address (a near pointer) is formed by adding the displacement to the address in the EIP register. The displacement 
is specified with a signed integer, allowing jumps either forward or backward in the instruction stream. 


An absolute address is a offset from address 0 of a segment. It can be specified in either of the following ways: 


° An address in a general-purpose register — This address is treated as a near pointer, which is copied into 
the EIP register. Program execution then continues at the new address within the current code segment. 


¢ An address specified using the standard addressing modes of the processor — Here, the address can 
be a near pointer or a far pointer. If the address is for a near pointer, the address is translated into an offset and 
copied into the EIP register. If the address is for a far pointer, the address is translated into a segment selector 
(which is copied into the CS register) and an offset (which is copied into the EIP register). 


In protected mode, the JMP instruction also allows jumps to a call gate, a task gate, and a task-state segment. 


Call and return instructions — The CALL (call procedure) and RET (return from procedure) instructions allow a 
jump from one procedure (or subroutine) to another and a subsequent jump back (return) to the calling procedure. 


The CALL instruction transfers program control from the current (or calling) procedure to another procedure (the 
called procedure). To allow a subsequent return to the calling procedure, the CALL instruction saves the current 
contents of the EIP register on the stack before jumping to the called procedure. The EIP register (prior to trans- 
ferring program control) contains the address of the instruction following the CALL instruction. When this address 
is pushed on the stack, it is referred to as the return instruction pointer or return address. 


The address of the called procedure (the address of the first instruction in the procedure being jumped to) is spec- 
ified in a CALL instruction the same way as it is in a JMP instruction (see “Jump instruction” on page 7-15). The 
address can be specified as a relative address or an absolute address. If an absolute address is specified, it can be 
either a near or a far pointer. 


The RET instruction transfers program control from the procedure currently being executed (the called procedure) 
back to the procedure that called it (the calling procedure). Transfer of control is accomplished by copying the 
return instruction pointer from the stack into the EIP register. Program execution then continues with the instruc- 
tion pointed to by the EIP register. 


The RET instruction has an optional operand, the value of which is added to the contents of the ESP register as part 
of the return operation. This operand allows the stack pointer to be incremented to remove parameters from the 
stack that were pushed on the stack by the calling procedure. 


See Section 6.4, “Calling Procedures Using CALL and RET,” for more information on the mechanics of making proce- 
dure calls with the CALL and RET instructions. 


Return from interrupt instruction — When the processor services an interrupt, it performs an implicit call to an 
interrupt-handling procedure. The IRET (return from interrupt) instruction returns program control from an inter- 
rupt handler to the interrupted procedure (that is, the procedure that was executing when the interrupt occurred). 
The IRET instruction performs a similar operation to the RET instruction (see “Call and return instructions” on page 
7-15) except that it also restores the EFLAGS register from the stack. The contents of the EFLAGS register are 
automatically stored on the stack along with the return instruction pointer when the processor services an inter- 
rupt. 


7.3.8.2 Conditional Transfer Instructions 


The conditional transfer instructions execute jumps or loops that transfer program control to another instruction in 
the instruction stream if specified conditions are met. The conditions for control transfer are specified with a set of 
condition codes that define various states of the status flags (CF, ZF, OF, PF, and SF) in the EFLAGS register. 


Conditional jump instructions — The Jcc (conditional) jump instructions transfer program control to a destina- 
tion instruction if the conditions specified with the condition code (cc) associated with the instruction are satisfied 
(see Table 7-4). If the condition is not satisfied, execution continues with the instruction following the Jcc instruc- 
tion. As with the JMP instruction, the transfer is one-way; that is, a return address is not saved. 
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Table 7-4. Conditional Jump Instructions 


Signed Conditional Jumps 
JG/JNLE 


(SF xor OF) or ZF) = 0 


Instruction Mnemonic Condition (Flag States) Description 
Unsigned Conditional Jumps 
JA/JNBE (CF or ZF) =0 Above/not below or equal 
JAE/JNB CF=0 Above or equal/not below 
JB/JNAE CF=1 Below/not above or equal 
JBE/JNA (CF or ZF) = 1 Below or equal/not above 
JC CF=1 Carry 
JE/Z ZF=1 Equal/zero 
JNC CF=0 Not carry 
JNE/JNZ ZF=0 Not equal/not zero 
JNP/JPO PF=0 Not parity/parity odd 
JP/JPE PF=1 Parity/parity even 
JCXZ CX =0 Register CX is zero 
JECXZ ECX = 0 Register ECX is zero 


Greater/not less or equal 


( 
JGE/JNL (SF xor OF) = 0 Greater or equal/not less 
JU/JNGE (SF xor OF) = 1 Less/not greater or equal 
JLE/JNG ((SF xor OF) or ZF) = 1 Less or equal/not greater 
JNO OF =0 Not overflow 
JNS SF =0 Not sign (non-negative) 
JO OF = 1 Overflow 
JS SF=1 Sign (negative) 


The destination operand specifies a relative address (a signed offset with respect to the address in the EIP register) 
that points to an instruction in the current code segment. The Jcc instructions do not support far transfers; 
however, far transfers can be accomplished with a combination of a Jcc and a JMP instruction (see “Jcc—Jump if 
Condition Is Met” in Chapter 3, “Instruction Set Reference, A-L,” of the Intel® 64 and IA-32 Architectures Software 
Developer’s Manual, Volume 2A). 


Table 7-4 shows the mnemonics for the Jcc instructions and the conditions being tested for each instruction. The 
condition code mnemonics are appended to the letter “J” to form the mnemonic for a Jcc instruction. The instruc- 
tions are divided into two groups: unsigned and signed conditional jumps. These groups correspond to the results 
of operations performed on unsigned and signed integers respectively. Those instructions listed as pairs (for 
example, JA/JNBE) are alternate names for the same instruction. Assemblers provide alternate names to make it 
easier to read program listings. 


The JCXZ and JECXZ instructions test the CX and ECX registers, respectively, instead of one or more status flags. 
See “Jump if zero instructions” on page 7-17 for more information about these instructions. 


Loop instructions — The LOOP, LOOPE (loop while equal), LOOPZ (loop while zero), LOOPNE (loop while not 
equal), and LOOPNZ (loop while not zero) instructions are conditional jump instructions that use the value of the 
ECX register as a count for the number of times to execute a loop. All the loop instructions decrement the count in 
the ECX register each time they are executed and terminate a loop when zero is reached. The LOOPE, LOOPZ, 
LOOPNE, and LOOPWZ instructions also accept the ZF flag as a condition for terminating the loop before the count 
reaches zero. 


The LOOP instruction decrements the contents of the ECX register (or the CX register, if the address-size attribute 
is 16), then tests the register for the loop-termination condition. If the count in the ECX register is non-zero, 
program control is transferred to the instruction address specified by the destination operand. The destination 
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operand is a relative address (that is, an offset relative to the contents of the EIP register), and it generally points 
to the first instruction in the block of code that is to be executed in the loop. When the count in the ECX register 
reaches zero, program control is transferred to the instruction immediately following the LOOP instruction, 
which terminates the loop. If the count in the ECX register is zero when the LOOP instruction is first executed, the 
register is pre-decremented to FFFFFFFFH, causing the loop to be executed 272 times. 


The LOOPE and LOOPZ instructions perform the same operation (they are mnemonics for the same instruction). 
These instructions operate the same as the LOOP instruction, except that they also test the ZF flag. 


If the count in the ECX register is not zero and the ZF flag is set, program control is transferred to the destination 
operand. When the count reaches zero or the ZF flag is clear, the loop is terminated by transferring program control 
to the instruction immediately following the LOOPE/LOOPZ instruction. 


The LOOPNE and LOOPNZ instructions (mnemonics for the same instruction) operate the same as the 
LOOPE/LOOPZ instructions, except that they terminate the loop if the ZF flag is set. 


Jump if zero instructions — The JECXZ (jump if ECX zero) instruction jumps to the location specified in the desti- 
nation operand if the ECX register contains the value zero. This instruction can be used in combination with a loop 
instruction (LOOP, LOOPE, LOOPZ, LOOPNE, or LOOPNZ) to test the ECX register prior to beginning a loop. As 
described in “Loop instructions” on page 7-16, the loop instructions decrement the contents of the ECX register 
before testing for zero. If the value in the ECX register is zero initially, it will be decremented to FFFFFFFFH on the 
first loop instruction, causing the loop to be executed 232 times. To prevent this problem, a JECXZ instruction can 
be inserted at the beginning of the code block for the loop, causing a jump out of the loop if the ECX register count 
is initially zero. When used with repeated string scan and compare instructions, the JECXZ instruction can deter- 
mine whether the loop terminated because the count reached zero or because the scan or compare conditions were 
satisfied. 


The JCXZ (jump if CX is zero) instruction operates the same as the JECXZ instruction when the 16-bit address-size 
attribute is used. Here, the CX register is tested for zero. 


7.3.8.3 Control Transfer Instructions in 64-Bit Mode 


In 64-bit mode, the operand size for all near branches (CALL, RET, JCC, JCXZ, JMP, and LOOP) is forced to 64 bits. 
The listed instructions update the 64-bit RIP without need for a REX operand-size prefix. 


Near branches in the following operations are forced to 64-bits (regardless of operand size prefixes): 
¢ Truncation of the size of the instruction pointer 

¢® Size of a stack pop or push, due to CALL or RET 

° Size of a stack-pointer increment or decrement, due to CALL or RET 

¢ Indirect-branch operand size 


Note that the displacement field for relative branches is still limited to 32 bits and the address size for near 
branches is not forced. 


Address size determines the register size (CX/ECX/RCX) used for JCXZ and LOOP. It also impacts the address 
calculation for memory indirect branches. Addresses size is 64 bits by default, although it can be over-ridden to 32 
bits (using a prefix). 


7.3.8.4 Software Interrupt Instructions 


The INT rn (software interrupt), INTO (interrupt on overflow), and BOUND (detect value out of range) instructions 
allow a program to explicitly raise a specified interrupt or exception, which in turn causes the handler routine for 
the interrupt or exception to be called. 


The INT rn instruction can raise any of the processor’s interrupts or exceptions by encoding the vector of the inter- 
rupt or exception in the instruction. This instruction can be used to support software generated interrupts or to test 
the operation of interrupt and exception handlers. 


The IRET (return from interrupt) instruction returns program control from an interrupt handler to the interrupted 
procedure. The IRET instruction performs a similar operation to the RET instruction. 
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The CALL (call procedure) and RET (return from procedure) instructions allow a jump from one procedure to 
another and a subsequent return to the calling procedure. EFLAGS register contents are automatically stored on 
the stack along with the return instruction pointer when the processor services an interrupt. 


The INTO instruction raises the overflow exception if the OF flag is set. If the flag is clear, execution continues 
without raising the exception. This instruction allows software to access the overflow exception handler explicitly to 
check for overflow conditions. 


The BOUND instruction compares a signed value against upper and lower bounds, and raises the “BOUND range 
exceeded” exception if the value is less than the lower bound or greater than the upper bound. This instruction is 
useful for operations such as checking an array index to make sure it falls within the range defined for the array. 


7.3.8.5 Software Interrupt Instructions in 64-bit Mode and Compatibility Mode 


In 64-bit mode, the stack size is 8 bytes wide. IRET must pop 8-byte items off the stack. SS:RSP pops uncondition- 
ally. BOUND is not supported. 


In compatibility mode, SS:RSP is popped only if the CPL changes. 


7.3.9 String Operations 


The GP instructions includes a set of string instructions that are designed to access large data structures; these 
are introduced in Section 7.3.9.1. Section 7.3.9.2 describes how REP prefixes can be used with these instructions 
to perform more complex repeated string operations. Certain processors optimize repeated string operations 
with fast-string operation, as described in Section 7.3.9.3. Section 7.3.9.4 explains how string operations can be 
used in 64-bit mode. 


7.3.9.1 String Instructions 


The MOVS (Move String), CMPS (Compare string), SCAS (Scan string), LODS (Load string), and STOS (Store 
string) instructions permit large data structures, such as alphanumeric character strings, to be moved and exam- 
ined in memory. These instructions operate on individual elements in a string, which can be a byte, word, or 
doubleword. The string elements to be operated on are identified with the ESI (source string element) and EDI 
(destination string element) registers. Both of these registers contain absolute addresses (offsets into a segment) 
that point to a string element. 


By default, the ESI register addresses the segment identified with the DS segment register. A segment-override 
prefix allows the ESI register to be associated with the CS, SS, ES, FS, or GS segment register. The EDI register 
addresses the segment identified with the ES segment register; no segment override is allowed for the EDI register. 
The use of two different segment registers in the string instructions permits operations to be performed on strings 
located in different segments. Or by associating the ESI register with the ES segment register, both the source and 
destination strings can be located in the same segment. (This latter condition can also be achieved by loading the 
DS and ES segment registers with the same segment selector and allowing the ESI register to default to the DS 
register. ) 


The MOVS instruction moves the string element addressed by the ESI register to the location addressed by the EDI 
register. The assembler recognizes three “short forms” of this instruction, which specify the size of the string to be 
moved: MOVSB (move byte string), MOVSW (move word string), and MOVSD (move doubleword string). 


The CMPS instruction subtracts the destination string element from the source string element and updates the 
status flags (CF, ZF, OF, SF, PF, and AF) in the EFLAGS register according to the results. Neither string element is 
written back to memory. The assembler recognizes three “short forms” of the CMPS instruction: CMPSB (compare 
byte strings), CMPSW (compare word strings), and CMPSD (compare doubleword strings). 


The SCAS instruction subtracts the destination string element from the contents of the EAX, AX, or AL register 
(depending on operand length) and updates the status flags according to the results. The string element and 
register contents are not modified. The following “short forms” of the SCAS instruction specify the operand length: 
SCASB (scan byte string), SCASW (scan word string), and SCASD (scan doubleword string). 


The LODS instruction loads the source string element identified by the ESI register into the EAX register (for a 
doubleword string), the AX register (for a word string), or the AL register (for a byte string). The “short forms” for 
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this instruction are LODSB (load byte string), LODSW (load word string), and LODSD (load doubleword string). This 
instruction is usually used in a loop, where other instructions process each element of the string after they are 
loaded into the target register. 


The STOS instruction stores the source string element from the EAX (doubleword string), AX (word string), or AL 
(byte string) register into the memory location identified with the EDI register. The “short forms” for this instruction 
are STOSB (store byte string), STOSW (store word string), and STOSD (store doubleword string). This instruction 
is also normally used in a loop. Here a string is commonly loaded into the register with a LODS instruction, oper- 
ated on by other instructions, and then stored again in memory with a STOS instruction. 


The I/O instructions (see Section 7.3.10, “I/O Instructions”) also perform operations on strings in memory. 


7.3.9.2 Repeated String Operations 


Each of the string instructions described in Section 7.3.9.1 perform one iteration of a string operation. To operate 
on strings longer than a doubleword, the string instructions can be combined with a repeat prefix (REP) to create a 
repeating instruction or be placed in a loop. 


When used in string instructions, the ESI and EDI registers are automatically incremented or decremented after 
each iteration of an instruction to point to the next element (byte, word, or doubleword) in the string. String oper- 
ations can thus begin at higher addresses and work toward lower ones, or they can begin at lower addresses and 
work toward higher ones. The DF flag in the EFLAGS register controls whether the registers are incremented (DF = 
0) or decremented (DF = 1). The STD and CLD instructions set and clear this flag, respectively. 


The following repeat prefixes can be used in conjunction with a count in the ECX register to cause a string instruc- 
tion to repeat: 


¢ REP — Repeat while the ECX register not zero. 
¢ REPE/REPZ — Repeat while the ECX register not zero and the ZF flag is set. 
¢ REPNE/REPNZ — Repeat while the ECX register not zero and the ZF flag is clear. 


When a string instruction has a repeat prefix, the operation executes until one of the termination conditions spec- 
ified by the prefix is satisfied. The REPE/REPZ and REPNE/REPNZ prefixes are used only with the CMPS and SCAS 
instructions. Also, note that a REP STOS instruction is the fastest way to initialize a large block of memory. 


7.3.9.3 Fast-String Operation 


To improve performance, more recent processors support modifications to the processor’s operation during the 
string store operations initiated with the MOVS, MOVSB, STOS, and STOSB instructions. This optimized operation, 
called fast-string operation, is used when the execution of one of those instructions meets certain initial condi- 
tions (see below). Instructions using fast-string operation effectively operate on the string in groups that may 
include multiple elements of the native data size (byte, word, doubleword, or quadword). With fast-string opera- 
tion, the processor recognizes interrupts and data breakpoints only on boundaries between these groups. Fast- 
string operation is used only if the source and destination addresses both use either the WB or WC memory types. 


The initial conditions for fast-string operation are implementation-specific and may vary with the native string size. 
Examples of parameters that may impact the use of fast-string operation include the following: 


¢ the alignment indicated in the EDI and ESI alignment registers; 
¢ the address order of the string operation; 

¢ the value of the initial operation counter (ECX); and 

° the difference between the source and destination addresses. 


NOTE 


Initial conditions for fast-string operation in future Intel 64 or IA-32 processor families may differ 
from above. The Inte/® 64 and IA-32 Architectures Optimization Reference Manual may contain 
model-specific information. 


Software can disable fast-string operation by clearing the fast-string-enable bit (bit 0) of IA32_MISC_ENABLE 
MSR. However, Intel recommends that system software always enable fast-string operation. 
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When fast-string operation is enabled (because IA32_MISC_ENABLE[0] = 1), some processors may further 
enhance the operation of the REP MOVSB and REP STOSB instructions. A processor supports these enhancements 
if CPUID.(EAX=07H, ECX=0H):EBX[bit 9] is 1. The Inte/® 64 and IA-32 Architectures Optimization Reference 
Manual may include model-specific recommendations for use of these enhancements. 


The stores produced by fast-string operation may appear to execute out of order. Software dependent upon 
sequential store ordering should not use string operations for the entire data structure to be stored. Data and 
semaphores should be separated. Order-dependent code should write to a discrete semaphore variable after any 
string operations to allow correctly ordered data to be seen by all processors. Atomicity of load and store operations 
is guaranteed only for native data elements of the string with native data size, and only if they are included in a 
single cache line. See Section 8.2.4, “Fast-String Operation and Out-of-Order Stores” of Inte/® 64 and IA-32 Archi- 
tectures Software Developer’s Manual, Volume 3A. 


7.3.9.4 String Operations in 64-Bit Mode 


The behavior of MOVS (Move String), CMPS (Compare string), SCAS (Scan string), LODS (Load string), and STOS 
(Store string) instructions in 64-bit mode is similar to their behavior in non-64-bit modes, with the following differ- 
ences: 


¢ The source operand is specified by RSI or DS:ESI, depending on the address size attribute of the operation. 


¢ The destination operand is specified by RDI or DS:EDI, depending on the address size attribute of the 
operation. 


* Operation on 64-bit data is supported by using the REX.W prefix. 


When using REP prefixes for string operations in 64-bit mode, the repeat count is specified by RCX or ECX 
(depending on the address size attribute of the operation). The default address size is 64 bits. 


7.3.10 I/O Instructions 


The IN (input from port to register), INS (input from port to string), OUT (output from register to port), and OUTS 
(output string to port) instructions move data between the processor’s I/O ports and either a register or memory. 


The register I/O instructions (IN and OUT) move data between an I/O port and the EAX register (32-bit I/O), the 
AX register (16-bit I/O), or the AL (8-bit I/O) register. The I/O port being read or written to is specified with an 
immediate operand or an address in the DX register. 


The block I/O instructions (INS and OUTS) instructions move blocks of data (strings) between an I/O port and 
memory. These instructions operate similar to the string instructions (see Section 7.3.9, “String Operations”). The 
ESI and EDI registers are used to specify string elements in memory and the repeat prefix (REP) is used to repeat 
the instructions to implement block moves. The assembler recognizes the following alternate mnemonics for these 
instructions: INSB (input byte), INSW (input word), and INSD (input doubleword), and OUTSB (output byte), 
OUTSW (output word), and OUTSD (output doubleword). 


The INS and OUTS instructions use an address in the DX register to specify the I/O port to be read or written to. 


7.3.11 I/O Instructions in 64-Bit Mode 


For I/O instructions to and from memory, the differences in 64-bit mode are: 
¢ The source operand is specified by RSI or DS:ESI, depending on the address size attribute of the operation. 


°* The destination operand is specified by RDI or DS:EDI, depending on the address size attribute of the 
operation. 


* Operation on 64-bit data is not encodable and REX prefixes are silently ignored. 
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7.3.12 Enter and Leave Instructions 


The ENTER and LEAVE instructions provide machine-language support for procedure calls in block-structured 
languages, such as C and Pascal. These instructions and the call and return mechanism that they support are 
described in detail in Section 6.6, “Procedure Calls for Block-Structured Languages”. 


7.3.13 Flag Control (EFLAG) Instructions 


The Flag Control (EFLAG) instructions allow the state of selected flags in the EFLAGS register to be read or modi- 
fied. For the purpose of this discussion, these instructions are further divided into subordinate subgroups of 
instructions that manipulate: 


® Carry and direction flags 
° The EFLAGS register 
¢ Interrupt flags 


7.3.13.1 Carry and Direction Flag Instructions 


The STC (set carry flag), CLC (clear carry flag), and CMC (complement carry flag) instructions allow the CF flag in 
the EFLAGS register to be modified directly. They are typically used to initialize the CF flag to a known state before 
an instruction that uses the flag in an operation is executed. They are also used in conjunction with the rotate-with- 
carry instructions (RCL and RCR). 


The STD (set direction flag) and CLD (clear direction flag) instructions allow the DF flag in the EFLAGS register to 
be modified directly. The DF flag determines the direction in which index registers ESI and EDI are stepped when 
executing string processing instructions. If the DF flag is clear, the index registers are incremented after each iter- 
ation of a string instruction; if the DF flag is set, the registers are decremented. 


7.3.13.2 | EFLAGS Transfer Instructions 


The EFLAGS transfer instructions allow groups of flags in the EFLAGS register to be copied to a register or memory 
or be loaded from a register or memory. 


The LAHF (load AH from flags) and SAHF (store AH into flags) instructions operate on five of the EFLAGS status 
flags (SF, ZF, AF, PF, and CF). The LAHF instruction copies the status flags to bits 7, 6, 4, 2, and 0 of the AH register, 
respectively. The contents of the remaining bits in the register (bits 5, 3, and 1) are unaffected, and the contents 
of the EFLAGS register remain unchanged. The SAHF instruction copies bits 7, 6, 4, 2, and 0 from the AH register 
into the SF, ZF, AF, PF, and CF flags, respectively in the EFLAGS register. 


The PUSHF (push flags), PUSHFD (push flags double), POPF (pop flags), and POPFD (pop flags double) instructions 
copy the flags in the EFLAGS register to and from the stack. The PUSHF instruction pushes the lower word of the 
EFLAGS register onto the stack (see Figure 7-11). The PUSHFD instruction pushes the entire EFLAGS register onto 
the stack (with the RF and VM flags read as clear). 
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Figure 7-11. Flags Affected by the PUSHF, POPF, PUSHFD, and POPFD Instructions 


The POPF instruction pops a word from the stack into the EFLAGS register. Only bits 11, 10, 8, 7, 6, 4, 2, and 0 of 
the EFLAGS register are affected with all uses of this instruction. If the current privilege level (CPL) of the current 
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code segment is 0 (most privileged), the IOPL bits (bits 13 and 12) also are affected. If the I/O privilege level 
(IOPL) is greater than or equal to the CPL, numerically, the IF flag (bit 9) also is affected. 


The POPFD instruction pops a doubleword into the EFLAGS register. This instruction can change the state of the AC 
bit (bit 18) and the ID bit (bit 21), as well as the bits affected by a POPF instruction. The restrictions for changing 
the IOPL bits and the IF flag that were given for the POPF instruction also apply to the POPFD instruction. 


7.3.13.3 Interrupt Flag Instructions 


The STI (set interrupt flag) and CLI (clear interrupt flag) instructions allow the interrupt IF flag in the EFLAGS 
register to be modified directly. The IF flag controls the servicing of hardware-generated interrupts (those received 
at the processor’s INTR pin). If the IF flag is set, the processor services hardware interrupts; if the IF flag is clear, 
hardware interrupts are masked. 


The ability to execute these instructions depends on the operating mode of the processor and the current privilege 
level (CPL) of the program or task attempting to execute these instructions. 


7.3.14 Flag Control (RFLAG) Instructions in 64-Bit Mode 
In 64-bit mode, the LAHF and SAHF instructions are supported if CPUID.80000001H:ECX.LAHF-SAHF[bit 0] = 1. 


PUSHF and POPF behave the same in 64-bit mode as in non-64-bit mode. PUSHFD always pushes 64-bit RFLAGS 
onto the stack (with the RF and VM flags read as clear). POPFD always pops a 64-bit value from the top of the stack 
and loads the lower 32 bits into RFLAGS. It then zero extends the upper bits of RFLAGS. 


7.3.15 Segment Register Instructions 


The processor provides a variety of instructions that address the segment registers of the processor directly. These 
instructions are only used when an operating system or executive is using the segmented or the real-address mode 
memory model. 


For the purpose of this discussion, these instructions are divided into subordinate subgroups of instructions that 
allow: 


° Segment-register load and store 
° Far control transfers 

° Software interrupt calls 

* Handling of far pointers 


7.3.15.1 |Segment-Register Load and Store Instructions 


The MOV instruction (introduced in Section 7.3.1.1, “General Data Movement Instructions”) and the PUSH and POP 
instructions (introduced in Section 7.3.1.4, “Stack Manipulation Instructions”) can transfer 16-bit segment selec- 
tors to and from segment registers (DS, ES, FS, GS, and SS). The transfers are always made to or from a segment 
register and a general-purpose register or memory. Transfers between segment registers are not supported. 


The POP and MOV instructions cannot place a value in the CS register. Only the far control-transfer versions of the 
JMP, CALL, and RET instructions (see Section 7.3.15.2, “Far Control Transfer Instructions”) affect the CS register 
directly. 


7.3.15.2 Far Control Transfer Instructions 


The JMP and CALL instructions (see Section 7.3.8, “Control Transfer Instructions”) both accept a far pointer as a 
destination to transfer program control to a segment other than the segment currently being pointed to by the CS 
register. When a far call is made with the CALL instruction, the current values of the EIP and CS registers are both 
pushed on the stack. 


The RET instruction (see “Call and return instructions” on page 7-15) can be used to execute a far return. Here, 
program control is transferred from a code segment that contains a called procedure back to the code segment that 
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contained the calling procedure. The RET instruction restores the values of the CS and EIP registers for the calling 
procedure from the stack. 


7.3.15.3 Software Interrupt Instructions 


The software interrupt instructions INT, INTO, and IRET (see Section 7.3.8.4, “Software Interrupt Instructions”) 
can also call and return from interrupt and exception handler procedures that are located in a code segment other 
than the current code segment. With these instructions, however, the switching of code segments is handled trans- 
parently from the application program. 


7.3.15.4 Load Far Pointer Instructions 


The load far pointer instructions LDS (load far pointer using DS), LES (load far pointer using ES), LFS (load far 
pointer using FS), LGS (load far pointer using GS), and LSS (load far pointer using SS) load a far pointer from 
memory into a segment register and a general-purpose general register. The segment selector part of the far 

pointer is loaded into the selected segment register and the offset is loaded into the selected general-purpose 
register. 


7.3.16 Miscellaneous Instructions 


The following instructions perform operations that are of interest to applications programmers. For the purpose of 
this discussion, these instructions are further divided into subordinate subgroups of instructions that provide for: 


e Address computations 

° Table lookup 

¢ Processor identification 

¢ NOP and undefined instruction entry 


7.3.16.1 Address Computation Instruction 


The LEA (load effective address) instruction computes the effective address in memory (offset within a segment) 
of a source operand and places it in a general-purpose register. This instruction can interpret any of the processor’s 
addressing modes and can perform any indexing or scaling that may be needed. It is especially useful for initial- 
izing the ESI or EDI registers before the execution of string instructions or for initializing the EBX register before an 
XLAT instruction. 


7.3.16.2 Table Lookup Instructions 


The XLAT and XLATB (table lookup) instructions replace the contents of the AL register with a byte read from a 
translation table in memory. The initial value in the AL register is interpreted as an unsigned index into the trans- 
lation table. This index is added to the contents of the EBX register (which contains the base address of the table) 
to calculate the address of the table entry. These instructions are used for applications such as converting character 
codes from one alphabet into another (for example, an ASCII code could be used to look up its EBCDIC equivalent 
in a table). 


7.3.16.3. Processor Identification Instruction 


The CPUID (processor identification) instruction returns information about the processor on which the instruction 
is executed. 


7.3.16.4 No-Operation and Undefined Instructions 


The NOP (no operation) instruction increments the EIP register to point at the next instruction, but affects nothing 
else. 
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The UD (undefined) instruction generates an invalid opcode exception. Intel reserves the opcode for this instruction 
for this function. The instruction is provided to allow software to test an invalid opcode exception handler. 


7.3.17 Random Number Generator Instructions 


The instructions for generating random numbers to comply with NIST SP800-90A, SP800-90B, and SP800-90C 
standards are described in this section. 


7.3.17.1 | RDRAND 


The RDRAND instruction returns a random number. All Intel processors that support the RDRAND instruction indi- 
cate the availability of the RDRAND instruction via reporting CPUID.O1H:ECX.RDRAND[bit 30] = 1. 


RDRAND returns random numbers that are supplied by a cryptographically secure, deterministic random bit gener- 
ator DRBG. The DRBG is designed to meet the NIST SP 800-90A standard. The DRBG is re-seeded frequently from 
an on-chip non-deterministic entropy source to guarantee data returned by RDRAND is statistically uniform, non- 
periodic and non-deterministic. 


In order for the hardware design to meet its security goals, the random number generator continuously tests itself 
and the random data it is generating. Runtime failures in the random number generator circuitry or statistically 
anomalous data occurring by chance will be detected by the self test hardware and flag the resulting data as being 
bad. In such extremely rare cases, the RDRAND instruction will return no data instead of bad data. 


Under heavy load, with multiple cores executing RDRAND in parallel, it is possible, though unlikely, for the demand 
of random numbers by software processes/threads to exceed the rate at which the random number generator 
hardware can supply them. This will lead to the RDRAND instruction returning no data transitorily. The RDRAND 
instruction indicates the occurrence of this rare situation by clearing the CF flag. 

The RDRAND instruction returns with the carry flag set (CF = 1) to indicate valid data is returned. It is recom- 
mended that software using the RDRAND instruction to get random numbers retry for a limited number of itera- 
tions while RDRAND returns CF=0 and complete when valid data is returned, indicated with CF=1. This will deal 
with transitory underflows. A retry limit should be employed to prevent a hard failure in the RNG (expected to be 
extremely rare) leading to a busy loop in software. 

The intrinsic primitive for RDRAND is defined to address software’s need for the common cases (CF = 1) and the 
rare situations (CF = 0). The intrinsic primitive returns a value that reflects the value of the carry flag returned by 
the underlying RDRAND instruction. The example below illustrates the recommended usage of an RDRAND intrinsic 
in a utility function, a loop to fetch a 64 bit random value with a retry count limit of 10. A C implementation might 
be written as follows: 


#define SUCCESS 1 
#define RETRY_LIMIT_ EXCEEDED 0 
#define RETRY_LIMIT 10 


int get random_64( unsigned __int 64 * arand) 
{int 1; 
for (i=0; i< RETRY LIMIT; i++) { 
if(_rdrand64_step(arand) ) return SUCCESS; 


} 
return RETRY LIMIT EXCEEDED; 


7.3.17.2 RDSEED 


The RDSEED instruction returns a random number. All Intel processors that support the RDSEED instruction indi- 
cate the availability of the RDSEED instruction via reporting CPUID.(EAX=07H, ECX=0H):EBX.RDSEED[bit 18] = 1. 
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RDSEED returns random numbers that are supplied by a cryptographically secure, enhanced non-deterministic 
random bit generator (Enhanced NRBG). The NRBG is designed to meet the NIST SP 800-90B and NIST SP800-90C 
standards. 

In order for the hardware design to meet its security goals, the random number generator continuously tests itself 
and the random data it is generating. Runtime failures in the random number generator circuitry or statistically 
anomalous data occurring by chance will be detected by the self test hardware and flag the resulting data as being 
bad. In such extremely rare cases, the RDSEED instruction will return no data instead of bad data. 

Under heavy load, with multiple cores executing RDSEED in parallel, it is possible for the demand of random 
numbers by software processes/threads to exceed the rate at which the random number generator hardware can 
supply them. This will lead to the RDSEED instruction returning no data transitorily. The RDSEED instruction indi- 
cates the occurrence of this situation by clearing the CF flag. 

The RDSEED instruction returns with the carry flag set (CF = 1) to indicate valid data is returned. It is recom- 
mended that software using the RDSEED instruction to get random numbers retry for a limited number of iterations 
while RDSEED returns CF=0 and complete when valid data is returned, indicated with CF=1. This will deal with 
transitory underflows. A retry limit should be employed to prevent a hard failure in the NRBG (expected to be 
extremely rare) leading to a busy loop in software. 

The intrinsic primitive for RDSEED is defined to address software’s need for the common cases (CF = 1) and the 
rare situations (CF = 0). The intrinsic primitive returns a value that reflects the value of the carry flag returned by 
the underlying RDSEED instruction. 
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CHAPTER 8 
PROGRAMMING WITH THE X87 FPU 


The x87 Floating-Point Unit (FPU) provides high-performance floating-point processing capabilities for use in 
graphics processing, scientific, engineering, and business applications. It supports the floating-point, integer, and 
packed BCD integer data types and the floating-point processing algorithms and exception handling architecture 
defined in the IEEE Standard 754 for Binary Floating-Point Arithmetic. 


This chapter describes the x87 FPU’s execution environment and instruction set. It also provides exception 
handling information that is specific to the x87 FPU. Refer to the following chapters or sections of chapters for addi- 
tional information about x87 FPU instructions and floating-point operations: 


° Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A & 2B, provide detailed descrip- 
tions of x87 FPU instructions. 


® Section 4.2.2, “Floating-Point Data Types,” Section 4.2.1.2, “Signed Integers,” and Section 4.7, “BCD and 
Packed BCD Integers,” describe the floating-point, integer, and BCD data types. 


° Section 4.9, “Overview of Floating-Point Exceptions,” Section 4.9.1, “Floating-Point Exception Conditions,” and 
Section 4.9.2, “Floating-Point Exception Priority,” give an overview of the floating-point exceptions that the x87 
FPU can detect and report. 


8.1 X87 FPU EXECUTION ENVIRONMENT 


The x87 FPU represents a separate execution environment within the IA-32 architecture (see Figure 8-1). This 
execution environment consists of eight data registers (called the x87 FPU data registers) and the following 
special-purpose registers: 


e Status register 

* Control register 

° Tag word register 

¢ Last instruction pointer register 

° Last data (operand) pointer register 

® Opcode register 

These registers are described in the following sections. 


The x87 FPU executes instructions from the processor’s normal instruction stream. The state of the x87 FPU is inde- 
pendent from the state of the basic execution environment and from the state of SSE/SSE2/SSE3 extensions. 


However, the x87 FPU and Intel MMX technology share state because the MMX registers are aliased to the x87 FPU 
data registers. Therefore, when writing code that uses x87 FPU and MMxX instructions, the programmer must 
explicitly manage the x87 FPU and MMxX state (see Section 9.5, “Compatibility with x87 FPU Architecture”). 


8.1.1 x87 FPU in 64-Bit Mode and Compatibility Mode 


In compatibility mode and 64-bit mode, x87 FPU instructions function like they do in protected mode. Memory 
operands are specified using the ModR/M, SIB encoding that is described in Section 3.7.5, “Specifying an Offset.” 


8.1.2 x87 FPU Data Registers 


The x87 FPU data registers (shown in Figure 8-1) consist of eight 80-bit registers. Values are stored in these regis- 
ters in the double extended-precision floating-point format shown in Figure 4-3. When floating-point, integer, or 
packed BCD integer values are loaded from memory into any of the x87 FPU data registers, the values are auto- 
matically converted into double extended-precision floating-point format (if they are not already in that format). 
When computation results are subsequently transferred back into memory from any of the x87 FPU registers, the 
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results can be left in the double extended-precision floating-point format or converted back into a shorter floating- 
point format, an integer format, or the packed BCD integer format. (See Section 8.2, “x87 FPU Data Types,” for a 
description of the data types operated on by the x87 FPU.) 


Data Registers 
79 78 64 63 0 
Sign! 
R7 | | Exponent Significand 
R6 
R5 
R4 
R3 
R2 
R1 
RO 
15 ) 47 0 
Routster Last Instruction Pointer (FCS:FIP) 
cane Last Data (Operand) Pointer (FDS:FDP) 
Tag 10 0 
Register Opcode 


Figure 8-1. x87 FPU Execution Environment 


The x87 FPU instructions treat the eight x87 FPU data registers as a register stack (see Figure 8-2). All addressing of 
the data registers is relative to the register on the top of the stack. The register number of the current top-of-stack 
register is stored in the TOP (stack TOP) field in the x87 FPU status word. Load operations decrement TOP by one 
and load a value into the new top-of-stack register, and store operations store the value from the current TOP 
register in memory and then increment TOP by one. (For the x87 FPU, a load operation is equivalent to a push and 
a store operation is equivalent to a pop.) Note that load and store operations are also available that do not push and 
pop the stack. 


FPU Data Register Stack 
7 
6 
ack 5 ST(2) 
4 ST(1) Top 
| 3 ST(0) «+ 011B 
2 
1 
0 


Figure 8-2. x87 FPU Data Register Stack 


If a load operation is performed when TOP is at 0, register wraparound occurs and the new value of TOP is set to 7. 
The floating-point stack-overflow exception indicates when wraparound might cause an unsaved value to be over- 
written (see Section 8.5.1.1, “Stack Overflow or Underflow Exception (#IS)”). 


Many floating-point instructions have several addressing modes that permit the programmer to implicitly operate 
on the top of the stack, or to explicitly operate on specific registers relative to the TOP. Assemblers support these 
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register addressing modes, using the expression ST(0), or simply ST, to represent the current stack top and ST(i) 
to specify the ith register from TOP in the stack (0 </< 7). For example, if TOP contains 011B (register 3 is the top 
of the stack), the following instruction would add the contents of two registers in the stack (registers 3 and 5): 


FADD ST, ST(2); 


Figure 8-3 shows an example of how the stack structure of the x87 FPU registers and instructions are typically used 
to perform a series of computations. Here, a two-dimensional dot product is computed, as follows: 


1. The first instruction (FLD value1) decrements the stack register pointer (TOP) and loads the value 5.6 from 
memory into ST(0). The result of this operation is shown in snap-shot (a). 


2. The second instruction multiplies the value in ST(0) by the value 2.4 from memory and stores the result in 
ST(0), shown in snap-shot (b). 


3. The third instruction decrements TOP and loads the value 3.8 in ST(O). 


The fourth instruction multiplies the value in ST(0) by the value 10.3 from memory and stores the result in 
ST(0), shown in snap-shot (c). 


5. The fifth instruction adds the value and the value in ST(1) and stores the result in ST(0), shown in snap-shot 


(d). 


Computation 

Dot Product = (5.6 x 2.4) + (3.8 x 10.3) 
Code: 

FLD valuel ;(a) valuel = 5.6 
FMUL value2 ;(b) value2 = 2.4 


FLD value3 ; value3 = 3.8 
FMUL value4 ;(c)value4 = 10.3 


FADD ST(1)_ ; (d) 
(a) (b) (c) (d) 
R7 R7 R7 R7 
R6 R6 R6 R6 
R5 R5 R5 R5 
R4 5.6 ST(0) R4 13.44 ST(0) R4 13.44 ST(1) R4 13.44 ST(1) 
R3 R3 R3 39.14 ST(0) R3 52.58 ST(0) 
R2 R2 R2 R2 
R1 R1 R1 R1 
RO RO RO RO 


Figure 8-3. Example x87 FPU Dot Product Computation 


The style of programming demonstrated in this example is supported by the floating-point instruction set. In cases 
where the stack structure causes computation bottlenecks, the FXCH (exchange x87 FPU register contents) 
instruction can be used to streamline a computation. 


8.1.2.1 Parameter Passing With the x87 FPU Register Stack 


Like the general-purpose registers, the contents of the x87 FPU data registers are unaffected by procedure calls, or 
in other words, the values are maintained across procedure boundaries. A calling procedure can thus use the x87 
FPU data registers (as well as the procedure stack) for passing parameter between procedures. The called proce- 
dure can reference parameters passed through the register stack using the current stack register pointer (TOP) 
and the ST(0) and ST(i) nomenclature. It is also common practice for a called procedure to leave a return value or 
result in register ST(0) when returning execution to the calling procedure or program. 
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When mixing MMX and x87 FPU instructions in the procedures or code sequences, the programmer is responsible 
for maintaining the integrity of parameters being passed in the x87 FPU data registers. If an MMX instruction is 
executed before the parameters in the x87 FPU data registers have been passed to another procedure, the param- 
eters may be lost (see Section 9.5, “Compatibility with x87 FPU Architecture”). 


8.1.3 x87 FPU Status Register 


The 16-bit x87 FPU status register (see Figure 8-4) indicates the current state of the x87 FPU. The flags in the x87 
FPU status register include the FPU busy flag, top-of-stack (TOP) pointer, condition code flags, exception summary 
status flag, stack fault flag, and exception flags. The x87 FPU sets the flags in this register to show the results of 
operations. 


FPU Busy 
Top of Stack Pointer 


151413 11109 8 7 6 5 4 3 2 0 
? C/C/C/E|S|P/U|O}|Z/D) 1 
2\/1/O/S/FJEJEJEJEJE/E 


Condition 
Code 
Exception |_ Status 


Stack Fault 
Exception Flags 
Precision 
Underflow 
Overflow 
Zero Divide 
Denormalized Operand 
Invalid Operation 


Figure 8-4. x87 FPU Status Word 


The contents of the x87 FPU status register (referred to as the x87 FPU status word) can be stored in memory using 
the FSTSW/FNSTSW, FSTENV/FNSTENV, FSAVE/FNSAVE, and FXSAVE instructions. It can also be stored in the AX 
register of the integer unit, using the FSTSW/FNSTSW instructions. 


8.1.3.1 Top of Stack (TOP) Pointer 


A pointer to the x87 FPU data register that is currently at the top of the x87 FPU register stack is contained in bits 
11 through 13 of the x87 FPU status word. This pointer, which is commonly referred to as TOP (for top-of-stack), 
is a binary value from 0 to 7. See Section 8.1.2, “x87 FPU Data Registers,” for more information about the TOP 
pointer. 


8.1.3.2 Condition Code Flags 


The four condition code flags (CO through C3) indicate the results of floating-point comparison and arithmetic oper- 
ations. Table 8-1 summarizes the manner in which the floating-point instructions set the condition code flags. 
These condition code bits are used principally for conditional branching and for storage of information used in 
exception handling (see Section 8.1.4, “Branching and Conditional Moves on Condition Codes”). 


As shown in Table 8-1, the C1 condition code flag is used for a variety of functions. When both the IE and SF flags 
in the x87 FPU status word are set, indicating a stack overflow or underflow exception (#IS), the C1 flag distin- 
guishes between overflow (C1 = 1) and underflow (Ci = 0). When the PE flag in the status word is set, indicating 
an inexact (rounded) result, the C1 flag is set to 1 if the last rounding by the instruction was upward. The FXAM 
instruction sets C1 to the sign of the value being examined. 
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The C2 condition code flag is used by the FPREM and FPREM1 instructions to indicate an incomplete reduction (or 
partial remainder). When a successful reduction has been completed, the CO, C3, and Ci condition code flags are 
set to the three least-significant bits of the quotient (Q2, Qi, and QO, respectively). See “FPREM1—Partial 
Remainder” in Chapter 3, “Instruction Set Reference, A-L,” of the Inte/® 64 and IA-32 Architectures Software 
Developer’s Manual, Volume 2A, for more information on how these instructions use the condition code flags. 


The FPTAN, FSIN, FCOS, and FSINCOS instructions set the C2 flag to 1 to indicate that the source operand is 
beyond the allowable range of +2°3 and clear the C2 flag if the source operand is within the allowable range. 


Where the state of the condition code flags are listed as undefined in Table 8-1, do not rely on any specific value in 
these flags. 


8.1.3.3 x87 FPU Floating-Point Exception Flags 


The six x87 FPU floating-point exception flags (bits 0 through 5) of the x87 FPU status word indicate that one or 
more floating-point exceptions have been detected since the bits were last cleared. The individual exception flags 
(IE, DE, ZE, OE, UE, and PE) are described in detail in Section 8.4, “x87 FPU Floating-Point Exception Handling.” 
Each of the exception flags can be masked by an exception mask bit in the x87 FPU control word (see Section 8.1.5, 
“x87 FPU Control Word”). The exception summary status flag (ES, bit 7) is set when any of the unmasked exception 
flags are set. When the ES flag is set, the x87 FPU exception handler is invoked, using one of the techniques 
described in Section 8.7, “Handling x87 FPU Exceptions in Software.” (Note that if an exception flag is masked, the 
x87 FPU will still set the appropriate flag if the associated exception occurs, but it will not set the ES flag.) 


The exception flags are “sticky” bits (once set, they remain set until explicitly cleared). They can be cleared by 
executing the FCLEX/FNCLEX (clear exceptions) instructions, by reinitializing the x87 FPU with the FINIT/FNINIT or 
FSAVE/FNSAVE instructions, or by overwriting the flags with an FRSTOR or FLDENV instruction. 


The B-bit (bit 15) is included for 8087 compatibility only. It reflects the contents of the ES flag. 


Table 8-1. Condition Code Interpretation 


Instruction co C3 C2 C1 
FCOM, FCOMP, FCOMPP, FICOM, FICOMP, FTST, Result of Comparison Operands O or #IS 
FUCOM, FUCOMP, FUCOMPP are not 
Comparable 
FCOMI, FCOMIP, FUCOMI, FUCOMIP Undefined. (These instructions set the #IS 
status flags in the EFLAGS register.) 
FXAM Operand class Sign 
FPREM, FPREM1 Q2 Q1 0 = reduction QO or #IS 
complete 
1 = reduction 
incomplete 
F2XM1, FADD, FADDP, FBSTP, FCMOVcc, Undefined Roundup or #IS 


FIADD, FDIV, FDIVP, FDIVR, FDIVRP, FIDIV, 
FIDIVR, FIMUL, FIST, FISTP, FISUB, 
FISUBR,FMUL, FMULP, FPATAN, FRNDINT, 
FSCALE, FST, FSTP, FSUB, FSUBP, FSUBR, 
FSUBRP,FSQRT, FYL2X, FYL2XP1 


FCOS, FSIN, FSINCOS, FPTAN Undefined O = source Roundup or #IS 
operand within (Undefined if C2 = 
range 1) 
1 = source 
operand out of 
range 
FABS, FBLD, FCHS, FDECSTP, FILD, FINCSTP, Undefined Oor #IS 
FLD, Load Constants, FSTP (ext. prec.), FXCH, 
FXTRACT 
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Table 8-1. Condition Code Interpretation (Contd.) 


FLDENV, FRSTOR Each bit loaded from memory 

FFREE, FLDCW, FCLEX/FNCLEX, FNOP, 

FSTCW/FNSTCW, FSTENV/FNSTENV, Undefined 

FSTSW/FNSTSW, 

FINIT/FNINIT, FSAVE/FNSAVE 0 0 0 0 


8.1.3.4 Stack Fault Flag 


The stack fault flag (bit 6 of the x87 FPU status word) indicates that stack overflow or stack underflow has occurred 
with data in the x87 FPU data register stack. The x87 FPU explicitly sets the SF flag when it detects a stack overflow 
or underflow condition, but it does not explicitly clear the flag when it detects an invalid-arithmetic-operand condi- 
tion. 


When this flag is set, the condition code flag Ci indicates the nature of the fault: overflow (C1 = 1) and under- 
flow (C1 = 0). The SF flag is a “sticky” flag, meaning that after it is set, the processor does not clear it until it is 
explicitly instructed to do so (for example, by an FINIT/FNINIT, FCLEX/FNCLEX, or FSAVE/FNSAVE instruction). 


See Section 8.1.7, “x87 FPU Tag Word,” for more information on x87 FPU stack faults. 


8.1.4 Branching and Conditional Moves on Condition Codes 


The x87 FPU (beginning with the P6 family processors) supports two mechanisms for branching and performing 
conditional moves according to comparisons of two floating-point values. These mechanism are referred to here as 
the “old mechanism” and the “new mechanism.” 


The old mechanism is available in x87 FPU’s prior to the P6 family processors and in P6 family processors. This 
mechanism uses the floating-point compare instructions (FCOM, FCOMP, FCOMPP, FTST, FUCOMPP, FICOM, and 
FICOMP) to compare two floating-point values and set the condition code flags (CO through C3) according to the 
results. The contents of the condition code flags are then copied into the status flags of the EFLAGS register using 
a two step process (see Figure 8-5): 


1. The FSTSW AX instruction moves the x87 FPU status word into the AX register. 


2. The SAHF instruction copies the upper 8 bits of the AX register, which includes the condition code flags, into the 
lower 8 bits of the EFLAGS register. 


When the condition code flags have been loaded into the EFLAGS register, conditional jumps or conditional moves 
can be performed based on the new settings of the status flags in the EFLAGS register. 


15 x87 FPU Status Word 0 
Condition Status C clicle 
Code Flag 3 Paras 
co CF 
C1 (none) y 
C2 PF FSTSW AX Instruction 
C3 ZF 15 AX Register 0 
Cc c|c|c 
3 2\1/0 
SAHF Instruction 
31 EFLAGS Register 7 0 
Z P|,4\C 
F FI |e 


Figure 8-5. Moving the Condition Codes to the EFLAGS Register 
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The new mechanism is available beginning with the P6 family processors. Using this mechanism, the new floating- 
point compare and set EFLAGS instructions (FCOMI, FCOMIP, FUCOMI, and FUCOMIP) compare two floating-point 
values and set the ZF, PF, and CF flags in the EFLAGS register directly. A single instruction thus replaces the three 
instructions required by the old mechanism. 


Note also that the FCMOVcc instructions (also new in the P6 family processors) allow conditional moves of floating- 
point values (values in the x87 FPU data registers) based on the setting of the status flags (ZF, PF, and CF) in the 
EFLAGS register. These instructions eliminate the need for an IF statement to perform conditional moves of 
floating-point values. 


8.1.5 x87 FPU Control Word 


The 16-bit x87 FPU control word (see Figure 8-6) controls the precision of the x87 FPU and rounding method used. 
It also contains the x87 FPU floating-point exception mask bits. The control word is cached in the x87 FPU control 
register. The contents of this register can be loaded with the FLDCW instruction and stored in memory with the 
FSTCW/FNSTCW instructions. 


Infinity Control 


Rounding Control 
[ Precision Control 


1514131211109 876543210 


x} Ro | PC | | ral nalna] in| a 
Exception Masks 
Precision 
Underflow 
Overflow 
Zero Divide 


Denormal Operand 
Invalid Operation 


Reserved 


Figure 8-6. x87 FPU Control Word 


When the x87 FPU is initialized with either an FINIT/FNINIT or FSAVE/FNSAVE instruction, the x87 FPU control 
word is set to 037FH, which masks all floating-point exceptions, sets rounding to nearest, and sets the x87 FPU 
precision to 64 bits. 


8.1.5.1 x87 FPU Floating-Point Exception Mask Bits 


The exception-flag mask bits (bits 0 through 5 of the x87 FPU control word) mask the 6 floating-point exception 
flags in the x87 FPU status word. When one of these mask bits is set, its corresponding x87 FPU floating-point 
exception is blocked from being generated. 


8.1.5.2 Precision Control Field 


The precision-control (PC) field (bits 8 and 9 of the x87 FPU control word) determines the precision (64, 53, or 24 
bits) of floating-point calculations made by the x87 FPU (see Table 8-2). The default precision is double extended 
precision, which uses the full 64-bit significand available with the double extended-precision floating-point format 
of the x87 FPU data registers. This setting is best suited for most applications, because it allows applications to take 
full advantage of the maximum precision available with the x87 FPU data registers. 
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Table 8-2. Precision Control Field (PC) 


Precision PC Field 
Single Precision (24 bits) 00B 
Reserved 01B 
Double Precision (53 bits) 10B 
Double Extended Precision (64 bits) 11B 


The double precision and single precision settings reduce the size of the significand to 53 bits and 24 bits, respec- 
tively. These settings are provided to support IEEE Standard 754 and to provide compatibility with the specifica- 
tions of certain existing programming languages. Using these settings nullifies the advantages of the double 
extended-precision floating-point format's 64-bit significand length. When reduced precision is specified, the 
rounding of the significand value clears the unused bits on the right to zeros. 


The precision-control bits only affect the results of the following floating-point instructions: FADD, FADDP, FIADD, 
FSUB, FSUBP, FISUB, FSUBR, FSUBRP, FISUBR, FMUL, FMULP, FIMUL, FDIV, FDIVP, FIDIV, FDIVR, FDIVRP, FIDIVR, 
and FSQRT. 


8.1.5.3 Rounding Control Field 


The rounding-control (RC) field of the x87 FPU control register (bits 10 and 11) controls how the results of x87 FPU 
floating-point instructions are rounded. See Section 4.8.4, “Rounding,” for a discussion of rounding of floating- 
point values; See Section 4.8.4.1, “Rounding Control (RC) Fields”, for the encodings of the RC field. 


8.1.6 Infinity Control Flag 


The infinity control flag (bit 12 of the x87 FPU control word) is provided for compatibility with the Intel 287 Math 
Coprocessor; it is not meaningful for later version x87 FPU coprocessors or IA-32 processors. See Section 4.8.3.3, 
“Signed Infinities,” for information on how the x87 FPUs handle infinity values. 


8.1.7 x87 FPU Tag Word 


The 16-bit tag word (see Figure 8-7) indicates the contents of each the 8 registers in the x87 FPU data-register 
stack (one 2-bit tag per register). The tag codes indicate whether a register contains a valid number, zero, or a 
special floating-point number (NaN, infinity, denormal, or unsupported format), or whether it is empty. The x87 
FPU tag word is cached in the x87 FPU in the x87 FPU tag word register. When the x87 FPU is initialized with either 
an FINIT/FNINIT or FSAVE/FNSAVE instruction, the x87 FPU tag word is set to FFFFH, which marks all the x87 FPU 
data registers as empty. 


15 0 


TAG(7) | TAG(6) | TAG(5) | TAG(4) | TAG(3) | TAG(2) | TAG(1) | TAG(O) 


TAG Values 
00 — Valid 
01 — Zero 
10 — Special: invalid (NaN, unsupported), infinity, or denormal 
11 — Empty 


Figure 8-7. x87 FPU Tag Word 


Each tag in the x87 FPU tag word corresponds to a physical register (numbers 0 through 7). The current top-of- 
stack (TOP) pointer stored in the x87 FPU status word can be used to associate tags with registers relative to ST(0). 
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The x87 FPU uses the tag values to detect stack overflow and underflow conditions (see Section 8.5.1.1, “Stack 
Overflow or Underflow Exception (#IS)”). 


Application programs and exception handlers can use this tag information to check the contents of an x87 FPU data 
register without performing complex decoding of the actual data in the register. To read the tag register, it must be 
stored in memory using either the FSTENV/FNSTENV or FSAVE/FNSAVE instructions. The location of the tag word 
in memory after being saved with one of these instructions is shown in Figures 8-9 through 8-12. 


Software cannot directly load or modify the tags in the tag register. The FLDENV and FRSTOR instructions load an 
image of the tag register into the x87 FPU; however, the x87 FPU uses those tag values only to determine if the 
data registers are empty (11B) or non-empty (O0B, 01B, or 10B). 


If the tag register image indicates that a data register is empty, the tag in the tag register for that data register is 
marked empty (11B); if the tag register image indicates that the data register is non-empty, the x87 FPU reads the 
actual value in the data register and sets the tag for the register accordingly. This action prevents a program from 
setting the values in the tag register to incorrectly represent the actual contents of non-empty data registers. 


8.1.8 x87 FPU Instruction and Data (Operand) Pointers 


The x87 FPU stores pointers to the instruction and data (operand) for the last non-control instruction executed. 
These are the x87 FPU instruction pointer and x87 FPU data (operand) pointers; software can save these pointers 
to provide state information for exception handlers. The pointers are illustrated in Figure 8-1 (the figure illustrates 
the pointers as used outside 64-bit mode; see below). 


Note that the value in the x87 FPU data pointer is always a pointer to a memory operand. If the last non-control 
instruction that was executed did not have a memory operand, the value in the data pointer is undefined 
(reserved). If CPUID.(EAX=07H,ECX=0H):EBX[bit 6] = 1, the data pointer is updated only for x87 non-control 
instructions that incur unmasked x87 exceptions. 


The contents of the x87 FPU instruction and data pointers remain unchanged when any of the following instructions 
are executed: FCLEX/FNCLEX, FLDCW, FSTCW/FNSTCW, FSTSW/FNSTSW, FSTENV/FNSTENV, FLDENV, and 
WAIT/FWAIT. 


For all the x87 FPUs and Numeric Processor Extensions (NPXs) except the 8087, the x87 FPU instruction pointer 
points to any prefixes that preceded the instruction. For the 8087, the x87 FPU instruction pointer points only to 
the actual opcode. 


The x87 FPU instruction and data pointers each consists of an offset and a segment selector: 


° The x87 FPU Instruction Pointer Offset (FIP) comprises 64 bits on processors that support IA-32e mode; on 
other processors, it offset comprises 32 bits. 


¢ The x87 FPU Instruction Pointer Selector (FCS) comprises 16 bits. 


¢ The x87 FPU Data Pointer Offset (FDP) comprises 64 bits on processors that support IA-32e mode; on other 
processors, it offset comprises 32 bits. 


° The x87 FPU Data Pointer Selector (FDS) comprises 16 bits. 


The pointers are accessed by the FINIT/FNINIT, FLDENV, FRSTOR, FSAVE/FNSAVE, FSTENV/FNSTENV, FXRSTOR, 
FXSAVE, XRSTOR, XSAVE, and XSAVEOPT instructions as follows: 


e FINIT/FNINIT. Each instruction clears FIP, FCS, FDP, and FDS. 

¢ FLDENV, FRSTOR. These instructions use the memory formats given in Figures 8-9 through 8-12: 
— For each of FIP and FDP, each instruction loads the lower 32 bits from memory and clears the upper 32 bits. 
— If CRO.PE = 1, each instruction loads FCS and FDS from memory; otherwise, it clears them. 


¢ ~=FSAVE/FNSAVE, FSTENV/FNSTENV. These instructions use the memory formats given in Figures 8-9 through 
8-12. 


— Each instruction saves the lower 32 bits of each FIP and FDP into memory. the upper 32 bits are not saved. 


— If CRO.PE = 1, each instruction saves FCS and FDS into memory. If 
CPUID.(EAX=07H,ECX=0H):EBX[bit 13] = 1, the processor deprecates FCS and FDS; it saves each as 
OOOOH. 
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— After saving these data into memory, FSAVE/FNSAVE clears FIP, FCS, FDP, and FDS. 


¢ FXRSTOR, XRSTOR. These instructions load data from a memory image whose format depend on operating 
mode and the REX prefix. The memory formats are given in Tables 3-43, 3-46, and 3-47 in Chapter 3, 
“Instruction Set Reference, A-L,” of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 2A. 


— Outside of 64-bit mode or if REX.W = 0, the instructions operate as follows: 


¢ For each of FIP and FDP, each instruction loads the lower 32 bits from memory and clears the upper 32 
bits. 


¢ Each instruction loads FCS and FDS from memory. 

— In 64-bit mode with REX.W = 1, the instructions operate as follows: 
¢ Each instruction loads FIP and FDP from memory. 
¢ Each instruction clears FCS and FDS. 


e FXSAVE, XSAVE, and XSAVEOPT. These instructions store data into a memory image whose format depend on 
operating mode and the REX prefix. The memory formats are given in Tables 3-43, 3-46, and 3-47 in Chapter 
3, “Instruction Set Reference, A-L,” of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 2A. 


— Outside of 64-bit mode or if REX.W = 0, the instructions operate as follows: 


¢ Each instruction saves the lower 32 bits of each of FIP and FDP into memory. The upper 32 bits are not 
saved. 


¢ Each instruction saves FCS and FDS into memory. If CPUID.(EAX=07H,ECX=0H):EBX[bit 13] = 1, the 
processor deprecates FCS and FDS; it saves each as OOOOH. 


— In 64-bit mode with REX.W = 1, each instruction saves FIP and FDP into memory. FCS and FDS are not 
saved. 


8.1.9 Last Instruction Opcode 


The x87 FPU stores in the 11-bit x87 FPU opcode register (FOP) the opcode of the last x87 non-control instruction 
executed that incurred an unmasked x87 exception. (This information provides state information for exception 
handlers.) Only the first and second opcode bytes (after all prefixes) are stored in the x87 FPU opcode register. 
Figure 8-8 shows the encoding of these two bytes. Since the upper 5 bits of the first opcode byte are the same for 
all floating-point opcodes (11011B), only the lower 3 bits of this byte are stored in the opcode register. 


8.1.9.1 Fopcode Compatibility Sub-mode 


Some Pentium 4 and Intel Xeon processors provide program control over the value stored into FOP. Here, bit 2 of 
the IA32_MISC_ENABLE MSR enables (set) or disables (clear) the fopcode compatibility mode. 


If fopcode compatibility mode is enabled, FOP is defined as it had been in previous IA-32 implementations, as the 
opcode of the last x87 non-control instruction executed (even if that instruction did not incur an unmasked x87 
exception). 
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1st Instruction Byte 2nd Instruction Byte 
7 2 0 7 0 


10 \ 87 0 


x87 FPU Opcode Register 


Figure 8-8. Contents of x87 FPU Opcode Registers 


The fopcode compatibility mode should be enabled only when x87 FPU floating-point exception handlers are 
designed to use the fopcode to analyze program performance or restart a program after an exception has been 
handled. 


More recent Intel 64 processors do not support fopcode compatibility mode and do not allow software to set bit 2 
of the IA32_MISC_ENABLE MSR. 


8.1.10 Saving the x87 FPU’s State with FSTENV/FNSTENV and FSAVE/FNSAVE 


The FSTENV/FNSTENV and FSAVE/FNSAVE instructions store x87 FPU state information in memory for use by 
exception handlers and other system and application software. The FSTENV/FNSTENV instruction saves the 
contents of the status, control, tag, x87 FPU instruction pointer, x87 FPU data pointer, and opcode registers. The 
FSAVE/FNSAVE instruction stores that information plus the contents of the x87 FPU data registers. Note that the 
FSAVE/FNSAVE instruction also initializes the x87 FPU to default values (just as the FINIT/FNINIT instruction does) 
after it has saved the original state of the x87 FPU. 


The manner in which this information is stored in memory depends on the operating mode of the processor 
(protected mode or real-address mode) and on the operand-size attribute in effect (32-bit or 16-bit). See Figures 
8-9 through 8-12. In virtual-8086 mode or SMM, the real-address mode formats shown in Figure 8-12 is used. See 
Chapter 30, “System Management Mode,” of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 3C, for information on using the x87 FPU while in SMM. 


The FLDENV and FRSTOR instructions allow x87 FPU state information to be loaded from memory into the x87 FPU. 
Here, the FLDENV instruction loads only the status, control, tag, x87 FPU instruction pointer, x87 FPU data pointer, 
and opcode registers, and the FRSTOR instruction loads all the x87 FPU registers, including the x87 FPU stack 
registers. 


32-Bit Protected Mode Format 


31 16 15 0 
Control Word 
Status Word 
Tag Word 
FPU Instruction Pointer Offset (FIP) 12 
00000] Bits 10:0 of opcode | FPU Instruction Pointer Selector | 16 
FPU Data Pointer Offset (FDP) 20 
FPU Data Pointer Selector (FDS) | 24 


For instructions that also store x87 FPU data registers, the eight 
80-bit registers (RO-R7) follow the above structure in sequence. 


Figure 8-9. Protected Mode x87 FPU State Image in Memory, 32-Bit Format 
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32-Bit Real-Address Mode Format 
31 16 15 0 
Control Word 0 
Status Word 
Tag Word 8 
FIP[15:0] 12 
0000 FIP[31:16] FOP[10:0] 16 
FDP[15:0] 20 
0000 FDP[31:16] 000000000000 | 24 
For instructions that also store x87 FPU data registers, the eight 
80-bit registers (RO-R7) follow the above structure in sequence. 


Figure 8-10. Real Mode x87 FPU State Image in Memory, 32-Bit Format 


16-Bit Protected Mode Format 
15 0 


Control Word 
Status Word 
Tag Word 
FIP 
FCS 
FDP 

FDS 12 


> OO RN OO 


Figure 8-11. Protected Mode x87 FPU State Image in Memory, 16-Bit Format 


16-Bit Real-Address Mode and 


Virtual-8086 Mode Format 
15 


Control Word 
Status Word 
Tag Word 
FIP[15:0] 
FIP[19:16]| 0| Bits 10:0 of opcode 
FDP[15:0] 
FDP[19:16] 0}00000000000/ 12 


> ODO ODORN OC 


Figure 8-12. Real Mode x87 FPU State Image in Memory, 16-Bit Format 


8.1.11 Saving the x87 FPU's State with FXSAVE 


The FXSAVE and FXRSTOR instructions save and restore, respectively, the x87 FPU state along with the state of the 
XMM registers and the MXCSR register. Using the FXSAVE instruction to save the x87 FPU state has two benefits: 
(1) FXSAVE executes faster than FSAVE, and (2) FXSAVE saves the entire x87 FPU, MMX, and XMM state in one 
operation. See Section 10.5, “FXSAVE and FXRSTOR Instructions,” for additional information about these instruc- 
tions. 
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8.2 X87 FPU DATA TYPES 


The x87 FPU recognizes and operates on the following seven data types (see Figures 8-13): single-precision 
floating point, double-precision floating point, double extended-precision floating point, signed word integer, 
signed doubleword integer, signed quadword integer, and packed BCD decimal integers. 


For detailed information about these data types, see Section 4.2.2, “Floating-Point Data Types,” Section 4.2.1.2, 
“Signed Integers,” and Section 4.7, “BCD and Packed BCD Integers.” 


With the exception of the 80-bit double extended-precision floating-point format, all of these data types exist in 
memory only. When they are loaded into x87 FPU data registers, they are converted into double extended-preci- 
sion floating-point format and operated on in that format. 


Denormal values are also supported in each of the floating-point types, as required by IEEE Standard 754. Whena 
denormal number in single-precision or double-precision floating-point format is used as a source operand and the 
denormal exception is masked, the x87 FPU automatically normalizes the number when it is converted to double 
extended-precision format. 


When stored in memory, the least significant byte of an x87 FPU data-type value is stored at the initial address 
specified for the value. Successive bytes from the value are then stored in successively higher addresses in 
memory. The floating-point instructions load and store memory operands using only the initial address of the 
operand. 


Single-Precision Floating-Point 


Sin—>f[__ Exe. Se Fraction] 


3130 23 22 Implied Integer 9 


Double-Precision Floating-Point 


Sign—st| Exponent eT Fraction 


6362 52 51 Implied Integer 0 
Sign 

y Double Extended-Precision Floating-Point 
|} Exponent fe Fraction = 
7978 6463 62 Integer 0 

Word Integer 
15 14 0 
Doubleword Integer 
3130 0 
Quadword Integer 

Sign 63 62 0 


Packed BCD Integers 


|X | D17,D16 D15,D14 D13,D12,D11,D10, D9, D8, D7 D6 , D5 D4, D3, D2, D1, DO 


7978 7271 4 Bits = 1 BCD Digit 


oO 


Figure 8-13. x87 FPU Data Type Formats 


As a general rule, values should be stored in memory in double-precision format. This format provides sufficient 
range and precision to return correct results with a minimum of programmer attention. The single-precision format 
is useful for debugging algorithms, because rounding problems will manifest themselves more quickly in this 
format. The double extended-precision format is normally reserved for holding intermediate results in the x87 FPU 
registers and constants. Its extra length is designed to shield final results from the effects of rounding and over- 
flow/underflow in intermediate calculations. However, when an application requires the maximum range and preci- 
sion of the x87 FPU (for data storage, computations, and results), values can be stored in memory in double 
extended-precision format. 
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8.2.1 Indefinites 


For each x87 FPU data type, one unique encoding is reserved for representing the special value indefinite. The x87 
FPU produces indefinite values as responses to some masked floating-point invalid-operation exceptions. See 
Tables 4-1, 4-3, and 4-4 for the encoding of the integer indefinite, QNaN floating-point indefinite, and packed BCD 
integer indefinite, respectively. 


The binary integer encoding 100..00B represents either of two things, depending on the circumstances of its use: 
* The largest negative number supported by the format (-2!°, -23!, or -2®3) 
¢ The integer indefinite value 


If this encoding is used as a source operand (as in an integer load or integer arithmetic instruction), the x87 FPU 
interprets it as the largest negative number representable in the format being used. If the x87 FPU detects an 
invalid operation when storing an integer value in memory with an FIST/FISTP instruction and the invalid-operation 
exception is masked, the x87 FPU stores the integer indefinite encoding in the destination operand as a masked 
response to the exception. In situations where the origin of a value with this encoding may be ambiguous, the 
invalid-operation exception flag can be examined to see if the value was produced as a response to an exception. 


8.2.2 Unsupported Double Extended-Precision 
Floating-Point Encodings and Pseudo-Denormals 


The double extended-precision floating-point format permits many encodings that do not fall into any of the cate- 
gories shown in Table 4-3. Table 8-3 shows these unsupported encodings. Some of these encodings were supported 
by the Intel 287 math coprocessor; however, most of them are not supported by the Intel 387 math coprocessor 

and later IA-32 processors. These encodings are no longer supported due to changes made in the final version of 
IEEE Standard 754 that eliminated these encodings. 


Specifically, the categories of encodings formerly known as pseudo-NaNs, pseudo-infinities, and un-normal 
numbers are not supported and should not be used as operand values. The Intel 387 math coprocessor and later 
IA-32 processors generate an invalid-operation exception when these encodings are encountered as operands. 


Beginning with the Intel 387 math coprocessor, the encodings formerly known as pseudo-denormal numbers are 
not generated by IA-32 processors. When encountered as operands, however, they are handled correctly; that is, 
they are treated as denormals and a denormal exception is generated. Pseudo-denormal numbers should not be 
used as operand values. They are supported by current IA-32 processors (as described here) to support legacy 
code. 


Table 8-3. Unsupported Double Extended-Precision Floating-Point Encodings and Pseudo-Denormals 


Significand 
Class Sign Biased Exponent Integer Fraction 
Positive 0 11.11 0 11.11 
Pseudo-NaNs Quiet ; : : 
0 11.11 10..00 
0 11.11 0 01.11 
ci 0 1 1.1 1 00.01 
Positive Floating Point | Pseudo-infinity 0 11.11 0 00..00 
0 11.10 0 11.11 
Unnormals : : : 
0 00..01 00..00 
Pseudo-denormals 0 00..00 1 11.11 
0 00.00 00.00 
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Table 8-3. Unsupported Double Extended-Precision Floating-Point Encodings and Pseudo-Denormals (Contd.) 


Negative Floating Point | Pseudo-denormals 1 00..00 1 11.11 
1 00.00 00.00 
1 11.10 0 11.01 
Unnormals : : : 
1 00..01 00..00 
Pseudo-infinity 1 11.11 0 00..00 
Negative Pseudo-NaNs 1 11.11 0 01..11 
ere 1 11 d 1 00..01 
1 11.11 0 11.11 
Quiet : : : 
1 11.11 10..00 
< 15 bits > < 63 bits > 


8.3 X87 FPU INSTRUCTION SET 


The floating-point instructions that the x87 FPU supports can be grouped into six functional categories: 
° Data transfer instructions 

° Basic arithmetic instructions 

* Comparison instructions 

¢ Transcendental instructions 

¢ Load constant instructions 

¢ x87 FPU control instructions 


See Section , “CPUID.EAX=80000001H:ECX.PREFTEHCHW][bit 8]: if 1 indicates the processor supports the PREFT- 
EHCHW instruction. CPUID.(EAX=07H, ECX=0H):ECX.PREFTEHCHWT1[bit 0]: if 1 indicates the processor supports 
the PREFTEHCHWT1 instruction.,” for a list of the floating-point instructions by category. 


The following section briefly describes the instructions in each category. Detailed descriptions of the floating-point 
instructions are given in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A, 2B, 2C 
& 2D. 


8.3.1 Escape (ESC) Instructions 


All of the instructions in the x87 FPU instruction set fall into a class of instructions known as escape (ESC) instruc- 
tions. All of these instructions have a common opcode format, where the first byte of the opcode is one of the 
numbers from D8H through DFH. 


8.3.2 x87 FPU Instruction Operands 


Most floating-point instructions require one or two operands, located on the x87 FPU data-register stack or in 
memory. (None of the floating-point instructions accept immediate operands.) 


When an operand is located in a data register, it is referenced relative to the ST(0) register (the register at the top 
of the register stack), rather than by a physical register number. Often the ST(0) register is an implied operand. 


Operands in memory can be referenced using the same operand addressing methods described in Section 3.7, 
“Operand Addressing.” 
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8.3.3 Data Transfer Instructions 


The data transfer instructions (see Table 8-4) perform the following operations: 

¢ Load a floating-point, integer, or packed BCD operand from memory into the ST(0) register. 

¢ Store the value in an ST(0O) register to memory in floating-point, integer, or packed BCD format. 
° Move values between registers in the x87 FPU register stack. 


The FLD (load floating point) instruction pushes a floating-point operand from memory onto the top of the x87 FPU 
data-register stack. If the operand is in single-precision or double-precision floating-point format, it is automati- 
cally converted to double extended-precision floating-point format. This instruction can also be used to push the 
value in a selected x87 FPU data register onto the top of the register stack. 


The FILD (load integer) instruction converts an integer operand in memory into double extended-precision floating - 
point format and pushes the value onto the top of the register stack. The FBLD (load packed decimal) instruction 
performs the same load operation for a packed BCD operand in memory. 


Table 8-4. Data Transfer Instructions 


Floating Point Integer Packed Decimal 
FLD Load Floating Point FILD Load Integer FBLD Load Packed 
Decimal 

FST Store Floating Point FIST Store Integer 

FSTP Store Floating Point and FISTP Store Integer FBSTP Store Packed 
Pop and Pop Decimal and Pop 

FXCH Exchange Register 
Contents 

FCMOVcc Conditional Move 


The FST (store floating point) and FIST (store integer) instructions store the value in register ST(0) in memory in 
the destination format (floating point or integer, respectively). Again, the format conversion is carried out automat- 
ically. 


The FSTP (store floating point and pop), FISTP (store integer and pop), and FBSTP (store packed decimal and pop) 
instructions store the value in the ST(0) registers into memory in the destination format (floating point, integer, or 
packed BCD), then performs a pop operation on the register stack. A pop operation causes the ST(0) register to be 
marked empty and the stack pointer (TOP) in the x87 FPU control work to be incremented by 1. The FSTP instruc- 
tion can also be used to copy the value in the ST(0) register to another x87 FPU register [ST(i)]. 


The FXCH (exchange register contents) instruction exchanges the value in a selected register in the stack [ST(i)] 
with the value in ST(0). 


The FCMOVcc (conditional move) instructions move the value in a selected register in the stack [ST(i)] to register 
ST(0) if a condition specified with a condition code (cc) is satisfied (see Table 8-5). The condition being tested for 


is represented by the status flags in the EFLAGS register. The condition code mnemonics are appended to the 
letters “FCMOV” to form the mnemonic for a FCMOVcc instruction. 


Table 8-5. Floating-Point Conditional Move Instructions 


Instruction Mnemonic Status Flag States Condition Description 
FCMOVB CF=1 Below 

FCMOVNB CF=0 Not below 

FCMOVE ZF=1 Equal 

FCMOVNE ZF=0 Not equal 
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Table 8-5. Floating-Point Conditional Move Instructions (Contd.) 


Instruction Mnemonic Status Flag States Condition Description 
FCMOVBE CF=1 or ZF=1 Below or equal 
FCMOVNBE CF=0 or ZF=0 Not below nor equal 
FCMOVU PF=1 Unordered 

FCMOVNU PF=0 Not unordered 


Like the CMOVcc instructions, the FCMOVcc instructions are useful for optimizing small IF constructions. They also 
help eliminate branching overhead for IF operations and the possibility of branch mispredictions by the processor. 


Software can check if the FCMOVcc instructions are supported by checking the processor’s feature information with 
the CPUID instruction. 


8.3.4 Load Constant Instructions 


The following instructions push commonly used constants onto the top [ST(0)] of the x87 FPU register stack: 


FLDZ Load +0.0 
FLD1 Load +1.0 
FLDPI Load x 
FLDL2T Load log, 10 
FLDL2E Load logze 
FLDLG2 Load log392 
FLDLN2 Load log,2 


The constant values have full double extended-precision floating-point precision (64 bits) and are accurate to 
approximately 19 decimal digits. They are stored internally in a format more precise than double extended-preci- 
sion floating point. When loading the constant, the x87 FPU rounds the more precise internal constant according 
to the RC (rounding control) field of the x87 FPU control word. The inexact-result exception (#P) is not generated 
as aresult of this rounding, nor is the C1 flag set in the x87 FPU status word if the value is rounded up. See 
Section 8.3.8, “Approximation of Pi,” for information on the z constant. 


8.3.5 Basic Arithmetic Instructions 


The following floating-point instructions perform basic arithmetic operations on floating-point numbers. Where 
applicable, these instructions match IEEE Standard 754: 


FADD/FADDP Add floating point 

FIADD Add integer to floating point 
FSUB/FSUBP Subtract floating point 

FISUB Subtract integer from floating point 
FSUBR/FSUBRP Reverse subtract floating point 

FISUBR Reverse subtract floating point from integer 
FMUL/FMULP Multiply floating point 

FIMUL Multiply integer by floating point 
FDIV/FDIVP Divide floating point 

FIDIV Divide floating point by integer 
FDIVR/FDIVRP Reverse divide 

FIDIVR Reverse divide integer by floating point 
FABS Absolute value 

FCHS Change sign 
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FSQRT Square root 

FPREM Partial remainder 

FPREM1 IEEE partial remainder 

FRNDINT Round to integral value 
FXTRACT Extract exponent and significand 


The add, subtract, multiply and divide instructions operate on the following types of operands: 

° Two x87 FPU data registers 

¢ An x87 FPU data register and a floating-point or integer value in memory 

See Section 8.1.2, “x87 FPU Data Registers,” for a description of how operands are referenced on the data register 
stack. 


Operands in memory can be in single-precision floating-point, double-precision floating-point, word-integer, or 
doubleword-integer format. They are converted to double extended-precision floating-point format automatically. 


Reverse versions of the subtract (FSUBR) and divide (FDIVR) instructions enable efficient coding. For example, the 
following options are available with the FSUB and FSUBR instructions for operating on values in a specified x87 FPU 
data register ST(/) and the ST(0) register: 
FSUB: 

ST(0) := ST(O) — ST(/) 

ST(i) = ST(i) — ST(O) 
FSUBR: 

ST(0) := ST(i) — ST(O) 

ST(/) = ST(0) — ST(A 
These instructions eliminate the need to exchange values between the ST(0) register and another x87 FPU register 
to perform a subtraction or division. 


The pop versions of the add, subtract, multiply, and divide instructions offer the option of popping the x87 FPU 
register stack following the arithmetic operation. These instructions operate on values in the ST(/) and ST(0O) regis- 
ters, store the result in the ST(/) register, and pop the ST(O) register. 


The FPREM instruction computes the remainder from the division of two operands in the manner used by the Intel 
8087 and Intel 287 math coprocessors; the FPREM1 instruction computes the remainder in the manner specified in 
IEEE Standard 754. 


The FSQRT instruction computes the square root of the source operand. 


The FRNDINT instruction returns a floating-point value that is the integral value closest to the source value in the 
direction of the rounding mode specified in the RC field of the x87 FPU control word. 


The FABS, FCHS, and FXTRACT instructions perform convenient arithmetic operations. The FABS instruction 
produces the absolute value of the source operand. The FCHS instruction changes the sign of the source operand. 
The FXTRACT instruction separates the source operand into its exponent and fraction and stores each value in a 
register in floating-point format. 


8.3.6 Comparison and Classification Instructions 
The following instructions compare or classify floating-point values: 


FCOM/FCOMP/FCOMPPCompare floating point and set x87 FPU 
condition code flags. 


FUCOM/FUCOMP/FUCOMPPUnordered compare floating point and set 
x87 FPU condition code flags. 


FICOM/FICOMPCompare integer and set x87 FPU 
condition code flags. 
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FCOMI/FCOMIPCompare floating point and set EFLAGS 
status flags. 


FUCOMI/FUCOMIPUnordered compare floating point and 
set EFLAGS status flags. 


FTST Test (compare floating point with 0.0). 
FXAMExamine. 


Comparison of floating-point values differ from comparison of integers because floating-point values have four 
(rather than three) mutually exclusive relationships: less than, equal, greater than, and unordered. 


The unordered relationship is true when at least one of the two values being compared is a NaN or in an unsup- 
ported format. This additional relationship is required because, by definition, NaNs are not numbers, so they 
cannot have less than, equal, or greater than relationships with other floating-point values. 


The FCOM, FCOMP, and FCOMPP instructions compare the value in register ST(0) with a floating-point source 
operand and set the condition code flags (CO, C2, and C3) in the x87 FPU status word according to the results (see 
Table 8-6). 


If an unordered condition is detected (one or both of the values are NaNs or in an undefined format), a floating- 
point invalid-operation exception is generated. 


The pop versions of the instruction pop the x87 FPU register stack once or twice after the comparison operation is 
complete. 


The FUCOM, FUCOMP, and FUCOMPP instructions operate the same as the FCOM, FCOMP, and FCOMPP instructions. 
The only difference is that with the FUCOM, FUCOMP, and FUCOMPP instructions, if an unordered condition is 
detected because one or both of the operands are QNaNs, the floating-point invalid-operation exception is not 
generated. 


Table 8-6. Setting of x87 FPU Condition Code Flags for Floating-Point Number Comparisons 


Condition c3 C2 co 
ST(0) > Source Operand 0 0 0 
ST(0) < Source Operand 0 0 1 
ST(0) = Source Operand 1 0 0 
Unordered 1 1 1 


The FICOM and FICOMP instructions also operate the same as the FCOM and FCOMP instructions, except that the 
source operand is an integer value in memory. The integer value is automatically converted into an double 
extended-precision floating-point value prior to making the comparison. The FICOMP instruction pops the x87 FPU 
register stack following the comparison operation. 


The FTST instruction performs the same operation as the FCOM instruction, except that the value in register ST(0) 
is always compared with the value 0.0. 


The FCOMI and FCOMIP instructions were introduced into the IA-32 architecture in the P6 family processors. They 
perform the same comparison as the FCOM and FCOMP instructions, except that they set the status flags (ZF, PF, 
and CF) in the EFLAGS register to indicate the results of the comparison (see Table 8-7) instead of the x87 FPU 
condition code flags. The FCOMI and FCOMIP instructions allow condition branch instructions (Jcc) to be executed 
directly from the results of their comparison. 


Table 8-7. Setting of EFLAGS Status Flags for Floating-Point Number Comparisons 


Comparison Results ZF PF CF 
STO > ST(i) 0 0 0 
STO < ST(i) 0 0 1 
STO =ST(i) 1 0 0 
Unordered 1 1 1 
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Software can check if the FCOMI and FCOMIP instructions are supported by checking the processor’s feature infor- 
mation with the CPUID instruction. 


The FUCOMI and FUCOMIP instructions operate the same as the FCOMI and FCOMIP instructions, except that they 
do not generate a floating-point invalid-operation exception if the unordered condition is the result of one or both 
of the operands being a QNaN. The FCOMIP and FUCOMIP instructions pop the x87 FPU register stack following the 
comparison operation. 


The FXAM instruction determines the classification of the floating-point value in the ST(0) register (that is, whether 
the value is zero, a denormal number, a normal finite number, «, a NaN, or an unsupported format) or that the 
register is empty. It sets the x87 FPU condition code flags to indicate the classification (see “FKAM—Examine” in 
Chapter 3, “Instruction Set Reference, A-L,” of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 2A). It also sets the C1 flag to indicate the sign of the value. 


8.3.6.1 Branching on the x87 FPU Condition Codes 


The processor does not offer any control-flow instructions that branch on the setting of the condition code flags 
(CO, C2, and C3) in the x87 FPU status word. To branch on the state of these flags, the x87 FPU status word must 
first be moved to the AX register in the integer unit. The FSTSW AX (store status word) instruction can be used for 
this purpose. When these flags are in the AX register, the TEST instruction can be used to control conditional 
branching as follows: 


1. Check for an unordered result. Use the TEST instruction to compare the contents of the AX register with the 
constant 0400H (see Table 8-8). This operation will clear the ZF flag in the EFLAGS register if the condition code 
flags indicate an unordered result; otherwise, the ZF flag will be set. The JNZ instruction can then be used to 
transfer control (if necessary) to a procedure for handling unordered operands. 


Table 8-8. TEST Instruction Constants for Conditional Branching 


Order Constant Branch 
ST(0) > Source Operand 4500H JZ 
ST(0) < Source Operand 0100H JNZ 
ST(0) = Source Operand 4000H JNZ 
Unordered 0400H JNZ 


2. Check ordered comparison result. Use the constants given in Table 8-8 in the TEST instruction to test for a less 
than, equal to, or greater than result, then use the corresponding conditional branch instruction to transfer 
program control to the appropriate procedure or section of code. 


If a program or procedure has been thoroughly tested and it incorporates periodic checks for QNaN results, then it 
is not necessary to check for the unordered result every time a comparison is made. 


See Section 8.1.4, “Branching and Conditional Moves on Condition Codes,” for another technique for branching on 
x87 FPU condition codes. 


Some non-comparison x87 FPU instructions update the condition code flags in the x87 FPU status word. To ensure 
that the status word is not altered inadvertently, store it immediately following a comparison operation. 


8.3.7 Trigonometric Instructions 


The following instructions perform four common trigonometric functions: 


FSIN Sine 

FCOS Cosine 
FSINCOS Sine and cosine 
FPTAN Tangent 
FPATAN Arctangent 
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These instructions operate on the top one or two registers of the x87 FPU register stack and they return their 
results to the stack. The source operands for the FSIN, FCOS, FSINCOS, and FPTAN instructions must be given in 
radians; the source operand for the FPATAN instruction is given in rectangular coordinate units. 


The FSINCOS instruction returns both the sine and the cosine of a source operand value. It operates faster than 
executing the FSIN and FCOS instructions in succession. 


The FPATAN instruction computes the arctangent of ST(1) divided by ST(0), returning a result in radians. It is 
useful for converting rectangular coordinates to polar coordinates. 


See Section 8.3.8, “Approximation of Pi” and Section 8.3.10, “Transcendental Instruction Accuracy” for information 
regarding the accuracy of these instructions. 


8.3.8 Approximation of Pi 


When the argument (source operand) of a trigonometric function is within the domain of the function, the argu- 
ment is automatically reduced by the appropriate multiple of 2x through the same reduction mechanism used by 
the FPREM and FPREM1 instructions. The internal value of z (3.1415926...) that the x87 FPU uses for argument 
reduction and other computations, denoted as Pi in the expression below. The numerical value of Pi can be written 
as: 

Pi = Of * 2¢ 
where the fraction f is expressed in binary form as: 

f = CSOFDAA2 21680234 C 


(The spaces in the fraction above indicate 32-bit boundaries.) 


The internal approximation Pi of the value x has a 66 significant bits. Since the exact value of x represented in 
binary has the next 3 bits equal to 0, it means that Pi is the value of m rounded to nearest-even to 68 bits, and also 
the value of x rounded toward zero (truncated) to 69 bits. 


However, accuracy problems may arise because this relatively short finite approximation Pi of the number z is used 
for calculating the reduced argument of the trigonometric function approximations in the implementations of FSIN, 
FCOS, FSINCOS, and FPTAN. Alternately, this means that FSIN (x), FCOS (x), and FPTAN (x) are really approxi- 
mating the mathematical functions sin (x * 2 /Pi), cos (x * 1 / Pi), and tan (x * 2 / Pi), and not exactly sin (x), cos 
(x), and tan (x). (Note that FSINCOS is the equivalent of FSIN and FCOS combined together). The period of sin (x 
* x /Pi) for example is 2* Pi, and not 2n. 


See also Section 8.3.10, “Transcendental Instruction Accuracy” for more information on the accuracy of these func- 
tions. 


8.3.9 Logarithmic, Exponential, and Scale 


The following instructions provide two different logarithmic functions, an exponential function and a scale function: 


FYL2X Logarithm 
FYL2XP1 Logarithm epsilon 
F2XM1 Exponential 
FSCALE Scale 


The FYL2X and FYL2XP1 instructions perform two different base 2 logarithmic operations. The FYL2X instruction 
computes (y * log>x). This operation permits the calculation of the log of any base using the following equation: 


logy xX = (1/logz b) * logs x 


The FYL2XP1 instruction computes (y * logz(x + 1)). This operation provides optimum accuracy for values of x that 
are close to 0. 


The F2XM1 instruction computes (2% — 1). This instruction only operates on source values in the range -1.0 to +1.0. 
The FSCALE instruction multiplies the source operand by a power of 2. 
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8.3.10 Transcendental Instruction Accuracy 


New transcendental instruction algorithms were incorporated into the IA-32 architecture beginning with the 
Pentium processors. These new algorithms (used in transcendental instructions FSIN, FCOS, FSINCOS, FPTAN, 
FPATAN, F2XM1, FYL2X, and FYL2XP1) allow a higher level of accuracy than was possible in earlier IA-32 processors 
and x87 math coprocessors. The accuracy of these instructions is measured in terms of units in the last place 
(ulp). For a given argument x, let f(x) and F(x) be the correct and computed (approximate) function values, 
respectively. The error in ulps is defined to be: 


error = oo 
ak 63 


where k is an integer such that: 
Ls 2*ex) <2. 


With the Pentium processor and later IA-32 processors, the worst case error on transcendental functions is less 
than 1 ulp when rounding to the nearest (even) and less than 1.5 ulps when rounding in other modes. The func- 
tions are guaranteed to be monotonic, with respect to the input operands, throughout the domain supported by the 
instruction. 


However, for FSIN, FCOS, FSINCOS, and FPTAN which approximate periodic trigonometric functions, the previous 
statement about maximum ulp errors is true only when these instructions are applied to reduced argument (see 
Section 8.3.8, “Approximation of Pi”). This is due to the fact that only 66 significant bits are retained in the finite 
approximation Pi of the number x (3.1415926...), used internally for calculating the reduced argument in FSIN, 
FCOS, FSINCOS, and FPTAN. This approximation of z is not always sufficiently accurate for good argument reduc- 
tion. 


For single precision, the argument of FSIN, FCOS, FSINCOS, and FPTAN must exceed 200,000 radians in order for 
the error of the result to exceed 1 ulp when rounding to the nearest (even), or 1.5 ulps when rounding in other 
(directed) rounding modes. 


For double and double-extended precision, the ulp errors will grow above these thresholds for arguments much 
smaller in magnitude. The ulp errors increase significantly when the argument approaches the value of x (or Pi) for 
FSIN, and when it approaches x/2(or Pi/2) for FCOS, FSINCOS, and FPTAN. 


For all three IEEE precisions supported (32-bit single precision, 64-bit double precision, and 80-bit double- 
extended precision), applying FSIN, FCOS, FSINCOS, or FPTAN to arguments larger than a certain value can lead 
to reduced arguments (calculated internally) that are inaccurate or even very inaccurate in some cases. This leads 
to equally inaccurate approximations of the corresponding mathematical functions. In particular, arguments that 
are close to certain values will lose significance when reduced, leading to increased relative (and ulp) errors in the 
results of FSIN, FCOS, FSINCOS, and FPTAN. These values are: 


® any non-zero multiple of x for FSIN, 
* any multiple of x, plus x/2 for FCOS, and 
® any non-zero multiple of x/2 for FSINCOS and FPTAN. 


If the arguments passed to FSIN, FCOS, FSINCOS, and FPTAN are not close to these values then even the finite 
approximation Pi of x used internally for argument reduction will allow for results that have good accuracy. 


Therefore, in order to avoid such errors it is recommended to perform accurate argument reduction in software, 
and to apply FSIN, FCOS, FSINCOS, and FPTAN to reduced arguments only. Regardless of the target precision 
(single, double, or double-extended), it is safe to reduce the argument to a value smaller in absolute value than 
about 3x/4 for FSIN, and smaller than about 3x/8 for FCOS, FSINCOS, and FPTAN. 


The thresholds shown above are not exact. For example, accuracy measurements show that the double-extended 
precision result of FSIN will not have errors larger than 0.72 ulp for |x| < 2.82 (so |x| < 3x/4 will ensure good accu- 
racy, as 3n/4 < 2.82). On the same interval, double precision results from FSIN will have errors at most slightly 
larger than 0.5 ulp, and single precision results will be correctly rounded in the vast majority of cases. 


Likewise, the double-extended precision result of FCOS will not have errors larger than 0.82 ulp for |x| < 1.31 (so 
|x| < 3z/8 will ensure good accuracy, as 3n/8 < 1.31). On the same interval, double precision results from FCOS 
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will have errors at most slightly larger than 0.5 ulp, and single precision results will be correctly rounded in the vast 
majority of cases. 


FSINCOS behaves similarly to FSIN and FCOS, combined as a pair. 


Finally, the double-extended precision result of FPTAN will not have errors larger than 0.78 ulp for |x| < 1.25 (so 
|x| < 3x/8 will ensure good accuracy, as 3n/8 < 1.25). On the same interval, double precision results from FPTAN 
will have errors at most slightly larger than 0.5 ulp, and single precision results will be correctly rounded in the vast 
majority of cases. 


A recommended alternative in order to avoid the accuracy issues that might be caused by FSIN, FCOS, FSINCOS, 
and FPTAN, is to use good quality mathematical library implementations of the sin, cos, sincos, and tan functions, 
for example those from the Intel® Math Library available in the Intel® Compiler. 


The instructions FYL2X and FYL2XP1 are two operand instructions and are guaranteed to be within 1 ulp only when 
y equals 1. When y is not equal to 1, the maximum ulp error is always within 1.35 ulps in round to nearest mode. 
(For the two operand functions, monotonicity was proved by holding one of the operands constant. ) 


8.3.11 x87 FPU Control Instructions 


The following instructions control the state and modes of operation of the x87 FPU. They also allow the status of the 
x87 FPU to be examined: 


FINIT/FNINIT Initialize x87 FPU 

FLDCW Load x87 FPU control word 
FSTCW/FNSTCW Store x87 FPU control word 
FSTSW/FNSTSW Store x87 FPU status word 
FCLEX/FNCLEX Clear x87 FPU exception flags 

FLDENV Load x87 FPU environment 
FSTENV/FNSTENV Store x87 FPU environment 

FRSTOR Restore x87 FPU state 

FSAVE/FNSAVE Save x87 FPU state 

FINCSTP Increment x87 FPU register stack pointer 
FDECSTP Decrement x87 FPU register stack pointer 
FFREE Free x87 FPU register 

FNOP No operation 

WAIT/FWAIT Check for and handle pending unmasked x87 FPU exceptions 


The FINIT/FNINIT instructions initialize the x87 FPU and its internal registers to default values. 


The FLDCW instructions loads the x87 FPU control word register with a value from memory. The FSTCW/FNSTCW 
and FSTSW/FNSTSW instructions store the x87 FPU control and status words, respectively, in memory (or for an 
FSTSW/FNSTSW instruction in a general-purpose register). 


The FSTENV/FNSTENV and FSAVE/FNSAVE instructions save the x87 FPU environment and state, respectively, in 
memory. The x87 FPU environment includes all the x87 FPU’s control and status registers; the x87 FPU state 
includes the x87 FPU environment and the data registers in the x87 FPU register stack. (The FSAVE/FNSAVE 
instruction also initializes the x87 FPU to default values, like the FINIT/FNINIT instruction, after it saves the original 
state of the x87 FPU.) 


The FLDENV and FRSTOR instructions load the x87 FPU environment and state, respectively, from memory into the 
x87 FPU. These instructions are commonly used when switching tasks or contexts. 


The WAIT/FWAIT instructions are synchronization instructions. (They are actually mnemonics for the same 
opcode.) These instructions check the x87 FPU status word for pending unmasked x87 FPU exceptions. If any 
pending unmasked x87 FPU exceptions are found, they are handled before the processor resumes execution of the 
instructions (integer, floating-point, or system instruction) in the instruction stream. The WAIT/FWAIT instructions 
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are provided to allow synchronization of instruction execution between the x87 FPU and the processor's integer 
unit. See Section 8.6, “x87 FPU Exception Synchronization,” for more information on the use of the WAIT/FWAIT 
instructions. 


8.3.12 Waiting vs. Non-waiting Instructions 


All of the x87 FPU instructions except a few special control instructions perform a wait operation (similar to the 
WAIT/FWAIT instructions), to check for and handle pending unmasked x87 FPU floating-point exceptions, before 
they perform their primary operation (such as adding two floating-point numbers). These instructions are called 
waiting instructions. Some of the x87 FPU control instructions, such as FSTSW/FNSTSW, have both a waiting and 
a non-waiting version. The waiting version (with the “F” prefix) executes a wait operation before it performs its 
primary operation; whereas, the non-waiting version (with the “FN” prefix) ignores pending unmasked exceptions. 


Non-waiting instructions allow software to save the current x87 FPU state without first handling pending exceptions 
or to reset or reinitialize the x87 FPU without regard for pending exceptions. 


NOTES 


When operating a Pentium or Intel486 processor in MS-DOS compatibility mode, it is possible 
(under unusual circumstances) for a non-waiting instruction to be interrupted prior to being 
executed to handle a pending x87 FPU exception. 


When operating a P6 family, Pentium 4, or Intel Xeon processor in MS-DOS compatibility mode, 
non-waiting instructions can not be interrupted in this way. 


8.3.13. Unsupported x87 FPU Instructions 


The Intel 8087 instructions FENI and FDISI and the Intel 287 math coprocessor instruction FSETPM perform no 
function in the Intel 387 math coprocessor and later IA-32 processors. If these opcodes are detected in the instruc- 
tion stream, the x87 FPU performs no specific operation and no internal x87 FPU states are affected. 


8.4 X87 FPU FLOATING-POINT EXCEPTION HANDLING 


The x87 FPU detects the six classes of exception conditions described in Section 4.9, “Overview of Floating-Point 
Exceptions”: 


¢ Invalid operation (#1), with two subclasses: 
— Stack overflow or underflow (#IS) 
— Invalid arithmetic operation (#1A) 

¢ Denormalized operand (#D) 

°® Divide-by-zero (#Z) 

¢ Numeric overflow (#0) 

° Numeric underflow (#U) 

¢  Inexact result (precision) (#P) 


Each of the six exception classes has a corresponding flag bit in the x87 FPU status word and a mask bit in the x87 
FPU control word (see Section 8.1.3, “x87 FPU Status Register,” and Section 8.1.5, “x87 FPU Control Word,” respec- 
tively). In addition, the exception summary (ES) flag in the status word indicates when one or more unmasked 
exceptions has been detected. The stack fault (SF) flag (also in the status word) distinguishes between the two 
types of invalid-operation exceptions. 


The mask bits can be set with FLDCW, FRSTOR, or FXRSTOR; they can be read with either FSTCW/FNSTCW, 
FSAVE/FNSAVE, or FXSAVE. The flag bits can be read with the FSTSW/FNSTSW, FSAVE/FNSAVE, or FXSAVE instruc- 
tion. 
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NOTE 


Section 4.9.1, “Floating-Point Exception Conditions,” provides a general overview of how the IA-32 
processor detects and handles the various classes of floating-point exceptions. This information 
pertains to x87 FPU as well as SSE/SSE2/SSE3 extensions. 


The following sections give specific information about how the x87 FPU handles floating-point exceptions that are 
unique to the x87 FPU. 


8.4.1 Arithmetic vs. Non-arithmetic Instructions 


When dealing with floating-point exceptions, it is useful to distinguish between arithmetic instructions and non- 
arithmetic instructions. Non-arithmetic instructions have no operands or do not make substantial changes to 
their operands. Arithmetic instructions do make significant changes to their operands; in particular, they make 
changes that could result in floating-point exceptions being signaled. Table 8-9 lists the non-arithmetic and arith- 
metic instructions. It should be noted that some non-arithmetic instructions can signal a floating-point stack (fault) 
exception, but this exception is not the result of an operation on an operand. 


Table 8-9. Arithmetic and Non-arithmetic Instructions 


Non-arithmetic Instructions Arithmetic Instructions 
FABS F2XM1 
FCHS FADD/FADDP 
FCLEX FBLD 
FDECSTP FBSTP 
FFREE FCOM/FCOMP/FCOMPP 
FINCSTP FCOS 
FINIT/FNINIT FDIV/FDIVP/FDIVR/FDIVRP 
FLD (register-to-register) FIADD 
FLD (extended format from memory) FICOM/FICOMP 
FLD constant FIDIV/FIDIVR 
FLDCW FILD 
FLDENV FIMUL 
FNOP FIST/FISTP2 
FRSTOR FISUB/FISUBR 
FSAVE/FNSAVE FLD (single and double) 
FST/FSTP (register-to-register) FMUL/FMULP 
FSTP (extended format to memory) FPATAN 
FSTCW/FNSTCW FPREM/FPREM1 
FSTENV/FNSTENV FPTAN 
FSTSW/FNSTSW FRNDINT 
WAIT/FWAIT FSCALE 
FXAM FSIN 
FXCH FSINCOS 
FSQRT 
FST/FSTP (single and double) 
FSUB/FSUBP/FSUBR/FSUBRP 
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Table 8-9. Arithmetic and Non-arithmetic Instructions (Contd.) 


Non-arithmetic Instructions Arithmetic Instructions 
FTST 
FUCOM/FUCOMP/FUCOMPP 
FXTRACT 
FYL2X/FYL2XP1 

NOTE: 


1. The FISTTP instruction in SSE3 is an arithmetic x87 FPU instruction. 


8.5 X87 FPU FLOATING-POINT EXCEPTION CONDITIONS 


The following sections describe the various conditions that cause a floating-point exception to be generated by the 
x87 FPU and the masked response of the x87 FPU when these conditions are detected. Intel® 64 and IA-32 Archi- 
tectures Software Developer’s Manual, Volumes 2A & 2B, list the floating-point exceptions that can be signaled for 
each floating-point instruction. 


See Section 4.9.2, “Floating-Point Exception Priority,” for a description of the rules for exception precedence when 
more than one floating-point exception condition is detected for an instruction. 


8.5.1 Invalid Operation Exception 


The floating-point invalid-operation exception occurs in response to two sub-classes of operations: 
° Stack overflow or underflow (#IS) 
° Invalid arithmetic operand (#IA) 


The flag for this exception (IE) is bit 0 of the x87 FPU status word, and the mask bit (IM) is bit 0 of the x87 FPU 
control word. The stack fault flag (SF) of the x87 FPU status word indicates the type of operation that caused the 
exception. When the SF flag is set to 1, a stack operation has resulted in stack overflow or underflow; when the flag 
is cleared to 0, an arithmetic instruction has encountered an invalid operand. Note that the x87 FPU explicitly sets 
the SF flag when it detects a stack overflow or underflow condition, but it does not explicitly clear the flag when it 
detects an invalid-arithmetic-operand condition. As a result, the state of the SF flag can be 1 following an invalid- 
arithmetic-operation exception, if it was not cleared from the last time a stack overflow or underflow condition 
occurred. See Section 8.1.3.4, “Stack Fault Flag,” for more information about the SF flag. 


8.5.1.1 Stack Overflow or Underflow Exception (#IS) 


The x87 FPU tag word keeps track of the contents of the registers in the x87 FPU register stack (see Section 8.1.7, 
“x87 FPU Tag Word”). It then uses this information to detect two different types of stack faults: 


¢ Stack overflow — An instruction attempts to load a non-empty x87 FPU register from memory. A non-empty 
register is defined as a register containing a zero (tag value of 01), a valid value (tag value of 00), or a special 
value (tag value of 10). 


¢ Stack underflow — An instruction references an empty x87 FPU register as a source operand, including 
attempting to write the contents of an empty register to memory. An empty register has a tag value of 11. 


NOTES 


The term stack overflow originates from the situation where the program has loaded (pushed) eight 
values from memory onto the x87 FPU register stack and the next value pushed on the stack causes 
a stack wraparound to a register that already contains a value. 


The term stack underflow originates from the opposite situation. Here, a program has stored 
(popped) eight values from the x87 FPU register stack to memory and the next value popped from 
the stack causes stack wraparound to an empty register. 
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When the x87 FPU detects stack overflow or underflow, it sets the IE flag (bit 0) and the SF flag (bit 6) in the x87 
FPU status word to 1. It then sets condition-code flag C1 (bit 9) in the x87 FPU status word to 1 if stack overflow 
occurred or to 0 if stack underflow occurred. 


If the invalid-operation exception is masked, the x87 FPU returns the floating point, integer, or packed decimal 
integer indefinite value to the destination operand, depending on the instruction being executed. This value over- 
writes the destination register or memory location specified by the instruction. 


If the invalid-operation exception is not masked, a software exception handler is invoked (see Section 8.7, 
“Handling x87 FPU Exceptions in Software”) and the top-of-stack pointer (TOP) and source operands remain 
unchanged. 


8.5.1.2 


The x87 FPU is able to detect a variety of invalid arithmetic operations that can be coded in a program. These oper- 
ations are listed in Table 8-10. (This list includes the invalid operations defined in IEEE Standard 754.) 


When the x87 FPU detects an invalid arithmetic operand, it sets the IE flag (bit 0) in the x87 FPU status word to 1. 
If the invalid-operation exception is masked, the x87 FPU then returns an indefinite value or QNaN to the destina- 
tion operand and/or sets the floating-point condition codes as shown in Table 8-10. If the invalid-operation excep- 


Invalid Arithmetic Operand Exception (#IA) 


tion is not masked, a software exception handler is invoked (see Section 8.7, “Handling x87 FPU Exceptions in 
Software”) and the top-of-stack pointer (TOP) and source operands remain unchanged. 


Table 8-10. Invalid Arithmetic Operations and the Masked Responses to Them 


Condition 


Masked Response 


Any arithmetic operation on an operand that is in an unsupported 
format. 


Any arithmetic operation on a SNaN. 


Return the QNaN floating-point indefinite value to the 
destination operand. 


Return a QNaN to the destination operand (see Table 4-7). 


Ordered compare and test operations: one or both operands are 
NaNs. 


Addition: operands are opposite-signed infinities. 
Subtraction: operands are like-signed infinities. 


Set the condition code flags (CO, C2, and C3) in the x87 FPU 
status word or the CF, PF, and ZF flags in the EFLAGS register to 
111B (not comparable). 


Return the QNaN floating-point indefinite value to the 
destination operand. 


Multiplication: 2 by 0;O0 by «. 


Division: oo by ;0 by 0. 


Return the QNaN floating-point indefinite value to the 
destination operand. 


Return the QNaN floating-point indefinite value to the 
destination operand. 


Remainder instructions FPREM, FPREM1: modulus (divisor) is O or 
dividend is co. 


Trigonometric instructions FCOS, FPTAN, FSIN, FSINCOS: source 
operand is ©. 


Return the QNaN floating-point indefinite; clear condition code 
flag C2 to O. 


Return the QNaN floating-point indefinite; clear condition code 
flag C2 to O. 


FSQRT: negative operand (except FSQRT (-0) = -0); FYL2X: negative 
operand (except FYL2X (-0) = -o-); FYL2XP1: operand more 
negative than -1. 


Return the QNaN floating-point indefinite value to the 
destination operand. 


FBSTP: Converted value cannot be represented in 18 decimal digits, 
or source value is an SNaN, QNaN, +c-, or in an unsupported 
format. 


Store packed BCD integer indefinite value in the destination 
operand. 


FIST/FISTP: Converted value exceeds representable integer range 
of the destination operand, or source value is an SNaN, QNaN, +e°, 
or in an unsupported format. 


Store integer indefinite value in the destination operand. 


FXCH: one or both registers are tagged empty. 


Load empty registers with the QNaN floating-point indefinite 
value, then perform the exchange. 
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Normally, when one or both of the source operands is a QNaN (and neither is an SNaN or in an unsupported 
format), an invalid-operand exception is not generated. An exception to this rule is most of the compare instruc- 
tions (Such as the FCOM and FCOMI instructions) and the floating-point to integer conversion instructions 
(FIST/FISTP and FBSTP). With these instructions, a QNaN source operand will generate an invalid-operand excep- 
tion. 


8.5.2 Denormal Operand Exception (#D) 


The x87 FPU signals the denormal-operand exception under the following conditions: 


¢ If an arithmetic instruction attempts to operate on a denormal operand (see Section 4.8.3.2, “Normalized and 
Denormalized Finite Numbers”). 


¢ If an attempt is made to load a denormal single-precision or double-precision floating-point value into an x87 
FPU register. (If the denormal value being loaded is a double extended-precision floating-point value, the 
denormal-operand exception is not reported.) 


The flag (DE) for this exception is bit 1 of the x87 FPU status word, and the mask bit (DM) is bit 1 of the x87 FPU 
control word. 


When a denormal-operand exception occurs and the exception is masked, the x87 FPU sets the DE flag, then 
proceeds with the instruction. The denormal operand in single- or double-precision floating-point format is auto- 
matically normalized when converted to the double extended-precision floating-point format. Subsequent opera- 
tions will benefit from the additional precision of the internal double extended-precision floating-point format. 


When a denormal-operand exception occurs and the exception is not masked, the DE flag is set and a software 
exception handler is invoked (see Section 8.7, “Handling x87 FPU Exceptions in Software”). The top-of-stack 
pointer (TOP) and source operands remain unchanged. 


For additional information about the denormal-operation exception, see Section 4.9.1.2, “‘Denormal Operand 
Exception (#D).” 


8.5.3 Divide-By-Zero Exception (#Z) 


The x87 FPU reports a floating-point divide-by-zero exception whenever an instruction attempts to divide a finite 
non-zero operand by O. The flag (ZE) for this exception is bit 2 of the x87 FPU status word, and the mask bit (ZM) 
is bit 2 of the x87 FPU control word. The FDIV, FDIVP, FDIVR, FDIVRP, FIDIV, and FIDIVR instructions and the other 
instructions that perform division internally (FYL2X and FXTRACT) can report the divide-by-zero exception. 


When a divide-by-zero exception occurs and the exception is masked, the x87 FPU sets the ZE flag and returns the 
values shown in Table 8-10. If the divide-by-zero exception is not masked, the ZE flag is set, a software exception 
handler is invoked (see Section 8.7, “Handling x87 FPU Exceptions in Software”), and the top-of-stack pointer 
(TOP) and source operands remain unchanged. 


Table 8-11. Divide-By-Zero Conditions and the Masked Responses to Them 


Condition Masked Response 
Divide or reverse divide operation with a | Returns an © signed with the exclusive OR of the sign of the two operands to the 
0 divisor. destination operand. 
FYL2X instruction. Returns an co signed with the opposite sign of the non-zero operand to the destination 
operand. 
FXTRACT instruction. ST(1) is set to -co; ST(O) is set to O with the same sign as the source operand. 


8.5.4 Numeric Overflow Exception (#0) 


The x87 FPU reports a floating-point numeric overflow exception (#0) whenever the rounded result of an arith- 
metic instruction exceeds the largest allowable finite value that will fit into the floating-point format of the destina- 
tion operand. (See Section 4.9.1.4, “Numeric Overflow Exception (#0),” for additional information about the 
numeric overflow exception. ) 
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When using the x87 FPU, numeric overflow can occur on arithmetic operations where the result is stored in an x87 
FPU data register. It can also occur on store floating-point operations (using the FST and FSTP instructions), where 
a within-range value in a data register is stored in memory in a single-precision or double-precision floating-point 
format. The numeric overflow exception cannot occur when storing values in an integer or BCD integer format. 
Instead, the invalid-arithmetic-operand exception is signaled. 


The flag (OE) for the numeric-overflow exception is bit 3 of the x87 FPU status word, and the mask bit (OM) is bit 
3 of the x87 FPU control word. 


When a numeric-overflow exception occurs and the exception is masked, the x87 FPU sets the OE flag and returns 
one of the values shown in Table 4-10. The value returned depends on the current rounding mode of the x87 FPU 
(see Section 8.1.5.3, “Rounding Control Field”). 


The action that the x87 FPU takes when numeric overflow occurs and the numeric-overflow exception is not 
masked, depends on whether the instruction is supposed to store the result in memory or on the register stack. 


* Destination is a memory location — The OE flag is set and a software exception handler is invoked (see 
Section 8.7, “Handling x87 FPU Exceptions in Software”). The top-of-stack pointer (TOP) and source and 
destination operands remain unchanged. Because the data in the stack is in double extended-precision format, 
the exception handler has the option either of re-executing the store instruction after proper adjustment of the 
operand or of rounding the significand on the stack to the destination's precision as the standard requires. The 
exception handler should ultimately store a value into the destination location in memory if the program is to 
continue. 


¢* Destination is the register stack — The significand of the result is rounded according to current settings of 
the precision and rounding control bits in the x87 FPU control word and the exponent of the result is adjusted 
by dividing it by 224576. (For instructions not affected by the precision field, the significand is rounded to 
double-extended precision.) The resulting value is stored in the destination operand. Condition code bit Ci in 
the x87 FPU status word (called in this situation the “round-up bit”) is set if the significand was rounded upward 
and cleared if the result was rounded toward O. After the result is stored, the OE flag is set and a software 
exception handler is invoked. The scaling bias value 24,576 is equal to 3 « 2!3. Biasing the exponent by 24,576 
normally translates the number as nearly as possible to the middle of the double extended-precision floating- 
point exponent range so that, if desired, it can be used in subsequent scaled operations with less risk of causing 
further exceptions. 


When using the FSCALE instruction, massive overflow can occur, where the result is too large to be repre- 
sented, even with a bias-adjusted exponent. Here, if overflow occurs again, after the result has been biased, a 
properly signed ~ is stored in the destination operand. 


8.5.5 Numeric Underflow Exception (#U) 


The x87 FPU detects a potential floating-point numeric underflow condition whenever the result of an arithmetic 
instruction is non-zero and tiny; that is, the magnitude of the rounded result with unbounded exponent is non-zero 
and less than the smallest possible normalized, finite value that will fit into the floating-point format of the desti- 
nation operand. (See Section 4.9.1.5, “Numeric Underflow Exception (#U),” for additional information about the 
numeric underflow exception. ) 


Like numeric overflow, numeric underflow can occur on arithmetic operations where the result is stored in an x87 
FPU data register. It can also occur on store floating-point operations (with the FST and FSTP instructions), where 
a within-range value in a data register is stored in memory in the smaller single-precision or double-precision 
floating-point formats. A numeric underflow exception cannot occur when storing values in an integer or BCD 
integer format, because a value with magnitude less than 1 is always rounded to an integral value of 0 or 1, 
depending on the rounding mode in effect. 


The flag (UE) for the numeric-underflow exception is bit 4 of the x87 FPU status word, and the mask bit (UM) is bit 
4 of the x87 FPU control word. 


When a numeric-underflow condition occurs and the exception is masked, the x87 FPU performs the operation 
described in Section 4.9.1.5, “Numeric Underflow Exception (#U).” 


When the exception is not masked, the action of the x87 FPU depends on whether the instruction is supposed to 
store the result in a memory location or on the x87 FPU resister stack. 
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* Destination is a memory location — (Can occur only with a store instruction.) The UE flag is set and a 
software exception handler is invoked (see Section 8.7, “Handling x87 FPU Exceptions in Software”). The top- 
of-stack pointer (TOP) and source and destination operands remain unchanged, and no result is stored in 
memory. 

Because the data in the stack is in double extended-precision format, the exception handler has the option 
either of re-exchanges the store instruction after proper adjustment of the operand or of rounding the 
significand on the stack to the destination's precision as the standard requires. The exception handler should 
ultimately store a value into the destination location in memory if the program is to continue. 


* Destination is the register stack — The significand of the result is rounded according to current settings of 
the precision and rounding control bits in the x87 FPU control word and the exponent of the result is adjusted 
by multiplying it by 274°7°, (For instructions not affected by the precision field, the significand is rounded to 
double extended precision.) The resulting value is stored in the destination operand. Condition code bit C1 in 
the x87 FPU status register (acting here as a “round-up bit”) is set if the significand was rounded upward and 
cleared if the result was rounded toward O. After the result is stored, the UE flag is set and a software exception 
handler is invoked. The scaling bias value 24,576 is the same as is used for the overflow exception and has the 
same effect, which is to translate the result as nearly as possible to the middle of the double extended-precision 
floating-point exponent range. 


When using the FSCALE instruction, massive underflow can occur, where the magnitude of the result is too 
small to be represented, even with a bias-adjusted exponent. Here, if underflow occurs again after the result 
has been biased, a properly signed 0 is stored in the destination operand. 


8.5.6 Inexact-Result (Precision) Exception (#P) 


The inexact-result exception (also called the precision exception) occurs if the result of an operation is not exactly 
representable in the destination format. (See Section 4.9.1.6, “Inexact-Result (Precision) Exception (#P),” for 
additional information about the numeric overflow exception.) Note that the transcendental instructions (FSIN, 
FCOS, FSINCOS, FPTAN, FPATAN, F2XM1, FYL2X, and FYL2XP1) by nature produce inexact results. 


The inexact-result exception flag (PE) is bit 5 of the x87 FPU status word, and the mask bit (PM) is bit 5 of the x87 
FPU control word. 


If the inexact-result exception is masked when an inexact-result condition occurs and a numeric overflow or under- 
flow condition has not occurred, the x87 FPU handles the exception as describe in Section 4.9.1.6, “Inexact-Result 
(Precision) Exception (#P),” with one additional action. The C1 (round-up) bit in the x87 FPU status word is set to 
indicate whether the inexact result was rounded up (C1 is set) or “not rounded up” (Ci is cleared). In the “not 
rounded up” case, the least-significant bits of the inexact result are truncated so that the result fits in the destina- 
tion format. 


If the inexact-result exception is not masked when an inexact result occurs and numeric overflow or underflow has 
not occurred, the x87 FPU handles the exception as described in the previous paragraph and, in addition, invokes 
a software exception handler. 


If an inexact result occurs in conjunction with numeric overflow or underflow, the x87 FPU carries out one of the 
following operations: 


° If an inexact result occurs in conjunction with masked overflow or underflow, the OE or UE flag and the PE flag 
are set and the result is stored as described for the overflow or underflow exceptions (see Section 8.5.4, 
“Numeric Overflow Exception (#0),” or Section 8.5.5, “Numeric Underflow Exception (#U)”). If the inexact 
result exception is unmasked, the x87 FPU also invokes a software exception handler. 


° If an inexact result occurs in conjunction with unmasked overflow or underflow and the destination operand is 
a register, the OE or UE flag and the PE flag are set, the result is stored as described for the overflow or 
underflow exceptions (see Section 8.5.4, “Numeric Overflow Exception (#0),” or Section 8.5.5, “Numeric 
Underflow Exception (#U)”) and a software exception handler is invoked. 


If an unmasked numeric overflow or underflow exception occurs and the destination operand is a memory location 
(which can happen only for a floating-point store), the inexact-result condition is not reported and the C1 flag is 
cleared. 
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8.6 X87 FPU EXCEPTION SYNCHRONIZATION 


Because the integer unit and x87 FPU are separate execution units, it is possible for the processor to execute 
floating-point, integer, and system instructions concurrently. No special programming techniques are required to 
gain the advantages of concurrent execution. (Floating-point instructions are placed in the instruction stream along 
with the integer and system instructions.) However, concurrent execution can cause problems for floating-point 
exception handlers. 


This problem is related to the way the x87 FPU signals the existence of unmasked floating-point exceptions. 
(Special exception synchronization is not required for masked floating-point exceptions, because the x87 FPU 
always returns a masked result to the destination operand.) 


When a floating-point exception is unmasked and the exception condition occurs, the x87 FPU stops further execu- 
tion of the floating-point instruction and signals the exception event. On the next occurrence of a floating-point 
instruction or a WAIT/FWAIT instruction in the instruction stream, the processor checks the ES flag in the x87 FPU 
status word for pending floating-point exceptions. If floating-point exceptions are pending, the x87 FPU makes an 
implicit call (traps) to the floating-point software exception handler. The exception handler can then execute 
recovery procedures for selected or all floating-point exceptions. 


Synchronization problems occur in the time between the moment when the exception is signaled and when it is 
actually handled. Because of concurrent execution, integer or system instructions can be executed during this 
time. It is thus possible for the source or destination operands for a floating-point instruction that faulted to be 
overwritten in memory, making it impossible for the exception handler to analyze or recover from the exception. 


To solve this problem, an exception synchronizing instruction (either a floating-point instruction or a WAIT/FWAIT 
instruction) can be placed immediately after any floating-point instruction that might present a situation where 
state information pertaining to a floating-point exception might be lost or corrupted. Floating-point instructions 
that store data in memory are prime candidates for synchronization. For example, the following three lines of code 
have the potential for exception synchronization problems: 


FILD COUNT ;Floating-point instruction 
INC COUNT Integer instruction 
FSQRT ;Subsequent floating-point instruction 


In this example, the INC instruction modifies the source operand of the floating-point instruction, FILD. If an 
exception is signaled during the execution of the FILD instruction, the INC instruction would be allowed to over- 
write the value stored in the COUNT memory location before the floating-point exception handler is called. With the 
COUNT variable modified, the floating-point exception handler would not be able to recover from the error. 


Rearranging the instructions, as follows, so that the FSQRT instruction follows the FILD instruction, synchronizes 
floating-point exception handling and eliminates the possibility of the COUNT variable being overwritten before the 
floating-point exception handler is invoked. 


FILD COUNT Floating-point instruction 

FSQRT ;Subsequent floating-point instruction synchronizes 
yany exceptions generated by the FILD instruction. 

INC COUNT Integer instruction 


The FSQRT instruction does not require any synchronization, because the results of this instruction are stored in 
the x87 FPU data registers and will remain there, undisturbed, until the next floating-point or WAIT/FWAIT instruc- 
tion is executed. To absolutely ensure that any exceptions emanating from the FSQRT instruction are handled (for 
example, prior to a procedure call), a WAIT instruction can be placed directly after the FSQRT instruction. 


Note that some floating-point instructions (non-waiting instructions) do not check for pending unmasked excep- 
tions (see Section 8.3.11, “x87 FPU Control Instructions”). They include the FNINIT, FNSTENV, FNSAVE, FNSTSW, 
FNSTCW, and FNCLEX instructions. When an FNINIT, FNSTENV, FNSAVE, or FNCLEX instruction is executed, all 
pending exceptions are essentially lost (either the x87 FPU status register is cleared or all exceptions are masked). 
The FNSTSW and FNSTCW instructions do not check for pending interrupts, but they do not modify the x87 FPU 
status and control registers. A subsequent “waiting” floating-point instruction can then handle any pending excep- 
tions. 
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8.7 HANDLING X87 FPU EXCEPTIONS IN SOFTWARE 


The x87 FPU in Pentium and later IA-32 processors provides two different modes of operation for invoking a soft- 
ware exception handler for floating-point exceptions: native mode and MS-DOS compatibility mode. The mode of 
operation is selected by CRO.NE[bit 5]. (See Chapter 2, “System Architecture Overview,” in the Inte/® 64 and 
IA-32 Architectures Software Developer’s Manual, Volume 3A, for more information about the NE flag.) 


8.7.1 Native Mode 


The native mode for handling floating-point exceptions is selected by setting CRO.NE[bit 5] to 1. In this mode, if the 
x87 FPU detects an exception condition while executing a floating-point instruction and the exception is unmasked 
(the mask bit for the exception is cleared), the x87 FPU sets the flag for the exception and the ES flag in the x87 
FPU status word. It then invokes the software exception handler through the floating-point-error exception (#MF, 
exception vector 16), immediately before execution of any of the following instructions in the processor's instruc- 
tion stream: 


¢ The next floating-point instruction, unless it is one of the non-waiting instructions (FNINIT, FNCLEX, FNSTSW, 
FNSTCW, FNSTENV, and FNSAVE). 


° The next WAIT/FWAIT instruction. 
¢ The next MMX instruction. 


If the next floating-point instruction in the instruction stream is a non-waiting instruction, the x87 FPU executes the 
instruction without invoking the software exception handler. 


8.7.2 MS-DOS* Compatibility Sub-mode 


If CRO.NE[bit 5] is 0, the MS-DOS compatibility mode for handling floating-point exceptions is selected. In this 
mode, the software exception handler for floating-point exceptions is invoked externally using the processor's 
FERR#, INTR, and IGNNE# pins. This method of reporting floating-point errors and invoking an exception handler 
is provided to support the floating-point exception handling mechanism used in PC systems that are running the 
MS-DOS or Windows* 95 operating system. 


Using FERR# and IGNNE# to handle floating-point exception is deprecated by modern operating systems, this 
approach also limits newer processors to operate with one logical processor active. 


The MS-DOS compatibility mode is typically used as follows to invoke the floating-point exception handler: 


1. If the x87 FPU detects an unmasked floating-point exception, it sets the flag for the exception and the ES flag 
in the x87 FPU status word. 


2. If the IGNNE# pin is deasserted, the x87 FPU then asserts the FERR# pin either immediately, or else delayed 
(deferred) until just before the execution of the next waiting floating-point instruction or MMX instruction. 
Whether the FERR# pin is asserted immediately or delayed depends on the type of processor, the instruction, 
and the type of exception. 


3. Ifa preceding floating-point instruction has set the exception flag for an unmasked x87 FPU exception, the 
processor freezes just before executing the next WAIT instruction, waiting floating-point instruction, or MMX 
instruction. Whether the FERR# pin was asserted at the preceding floating-point instruction or is just now being 
asserted, the freezing of the processor assures that the x87 FPU exception handler will be invoked before the 
new floating-point (or MMX) instruction gets executed. 


4. The FERR# pin is connected through external hardware to IRQ13 of a cascaded, programmable interrupt 
controller (PIC). When the FERR# pin is asserted, the PIC is programmed to generate an interrupt 75H. 


5. The PIC asserts the INTR pin on the processor to signal the interrupt 75H. 


The BIOS for the PC system handles the interrupt 75H by branching to the interrupt 02H (NMI) interrupt 
handler. 


7. The interrupt 02H handler determines if the interrupt is the result of an NMI interrupt or a floating-point 
exception. 
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8. Ifa floating-point exception is detected, the interrupt 02H handler branches to the floating-point exception 
handler. 


If the IGNNE# pin is asserted, the processor ignores floating-point error conditions. This pin is provided to inhibit 
floating-point exceptions from being generated while the floating-point exception handler is servicing a previously 
signaled floating-point exception. 


Appendix D, “Guidelines for Writing SIMD Floating-Point Exception Handlers,” describes the MS-DOS compatibility 
mode in much greater detail. This mode is somewhat more complicated in the Intel486 and Pentium processor 
implementations, as described in Appendix D. 


8.7.3 Handling x87 FPU Exceptions in Software 


Section 4.9.3, “Typical Actions of a Floating-Point Exception Handler,” shows actions that may be carried out by a 
floating-point exception handler. The state of the x87 FPU can be saved with the FSTENV/FNSTENV or 
FSAVE/FNSAVE instructions (see Section 8.1.10, “Saving the x87 FPU’s State with FSTENV/FNSTENV and 
FSAVE/FNSAVE"). 


If the faulting floating-point instruction is followed by one or more non-floating-point instructions, it may not be 
useful to re-execute the faulting instruction. See Section 8.6, “x87 FPU Exception Synchronization,” for more infor- 
mation on synchronizing floating-point exceptions. 


In cases where the handler needs to restart program execution with the faulting instruction, the IRET instruction 
cannot be used directly. The reason for this is that because the exception is not generated until the next floating- 
point or WAIT/FWAIT instruction following the faulting floating-point instruction, the return instruction pointer on 
the stack may not point to the faulting instruction. To restart program execution at the faulting instruction, the 
exception handler must obtain a pointer to the instruction from the saved x87 FPU state information, load it into 
the return instruction pointer location on the stack, and then execute the IRET instruction. 
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CHAPTER 9 
PROGRAMMING WITH INTEL® MMX™ TECHNOLOGY 


The Intel MMX technology was introduced into the IA-32 architecture in the Pentium II processor family and 
Pentium processor with MMX technology. The extensions introduced in MMX technology support a single-instruc- 
tion, multiple-data (SIMD) execution model that is designed to accelerate the performance of advanced media and 
communications applications. 


This chapter describes MMX technology. 


9.1 OVERVIEW OF MMX TECHNOLOGY 


MMX technology defines a simple and flexible SIMD execution model to handle 64-bit packed integer data. This 
model adds the following features to the IA-32 architecture, while maintaining backwards compatibility with all IA- 
32 applications and operating-system code: 


° Eight new 64-bit data registers, called MMX registers 
° Three new packed data types: 
— 64-bit packed byte integers (signed and unsigned) 
— 64-bit packed word integers (signed and unsigned) 
— 64-bit packed doubleword integers (signed and unsigned) 
¢ Instructions that support the new data types and to handle MMX state management 
¢ Extensions to the CPUID instruction 


MMxX technology is accessible from all the IA32-architecture execution modes (protected mode, real address mode, 
and virtual 8086 mode). It does not add any new modes to the architecture. 


The following sections of this chapter describe MMX technology’s programming environment, including MMX 
register set, data types, and instruction set. Additional instructions that operate on MMX registers have been added 
to the IA-32 architecture by the SSE/SSE2 extensions. 

For more information, see: 


® Section 10.4.4, “SSE 64-Bit SIMD Integer Instructions,” describes MMX instructions added to the IA-32 archi- 
tecture with the SSE extensions. 


® Section 11.4.2, “SSE2 64-Bit and 128-Bit SIMD Integer Instructions,” describes MMX instructions added to the 
IA-32 architecture with SSE2 extensions. 


¢ Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A & 2B, give detailed descriptions 
of MMX instructions. 


* Chapter 12, “Intel® MMX™ Technology System Programming,” in the Inte/® 64 and IA-32 Architectures 
Software Developer’s Manual, Volume 3B, describes the manner in which MMX technology is integrated into the 
IA-32 system programming model. 


9.2 THE MMX TECHNOLOGY PROGRAMMING ENVIRONMENT 


Figure 9-1 shows the execution environment for MMX technology. All MMX instructions operate on MMX registers, 
the general-purpose registers, and/or memory as follows: 


° MMxX registers — These eight registers (see Figure 9-1) are used to perform operations on 64-bit packed 
integer data. They are named MMO through MM7. 


Vol.1 9-1 


PROGRAMMING WITH INTEL® MMX™ TECHNOLOGY 


Address Space 


232 4 


MMX Registers 
Eight 64-Bit 


General-Purpose 
Registers 
Eight 32-Bit 


Figure 9-1. MMX Technology Execution Environment 


¢ General-purpose registers — The eight general-purpose registers (see Figure 3-5) are used with existing IA- 
32 addressing modes to address operands in memory. (MMX registers cannot be used to address memory). 
General-purpose registers are also used to hold operands for some MMX technology operations. They are EAX, 
EBX, ECX, EDX, EBP, ESI, EDI, and ESP. 


9.2.1 MMX Technology in 64-Bit Mode and Compatibility Mode 


In compatibility mode and 64-bit mode, MMX instructions function like they do in protected mode. Memory oper- 
ands are specified using the ModR/M, SIB encoding described in Section 3.7.5. 


9.2.2 MMX Registers 


The MMxX register set consists of eight 64-bit registers (see Figure 9-2), that are used to perform calculations on 
the MMX packed integer data types. Values in MMX registers have the same format as a 64-bit quantity in memory. 


The MMX registers have two data access modes: 64-bit access mode and 32-bit access mode. The 64-bit access 
mode is used for: 


° 64-bit memory accesses 

° 64-bit transfers between MMX registers 

¢ All pack, logical, and arithmetic instructions 

® Some unpack instructions 

The 32-bit access mode is used for: 

¢ 32-bit memory accesses 

° 32-bit transfer between general-purpose registers and MMX registers 
® Some unpack instructions 
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Figure 9-2. MMX Register Set 


Although MMX registers are defined in the IA-32 architecture as separate registers, they are aliased to the registers 
in the FPU data register stack (RO through R7). 


See also Section 9.5, “Compatibility with x87 FPU Architecture.” 


9.2.3 MMxX Data Types 


MMX technology introduced the following 64-bit data types to the IA-32 architecture (see Figure 9-3): 

° 64-bit packed byte integers — eight packed bytes 

° 64-bit packed word integers — four packed words 

° 64-bit packed doubleword integers — two packed doublewords 

MMX instructions move 64-bit packed data types (packed bytes, packed words, or packed doublewords) and the 
quadword data type between MMX registers and memory or between MMxX registers in 64-bit blocks. However, 
when performing arithmetic or logical operations on the packed data types, MMX instructions operate in parallel on 


the individual bytes, words, or doublewords contained in MMX registers (see Section 9.2.5, “Single Instruction, 
Multiple Data (SIMD) Execution Model”). 


63 0 


63 0 


63 0 


Figure 9-3. Data Types Introduced with the MMX Technology 


9.2.4 Memory Data Formats 


When stored in memory: bytes, words and doublewords in the packed data types are stored in consecutive 
addresses. The least significant byte, word, or doubleword is stored at the lowest address and the most significant 
byte, word, or doubleword is stored at the high address. The ordering of bytes, words, or doublewords in memory 
is always little endian. That is, the bytes with the low addresses are less significant than the bytes with high 
addresses. 
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9.2.5 Single Instruction, Multiple Data (SIMD) Execution Model 


MMX technology uses the single instruction, multiple data (SIMD) technique for performing arithmetic and logical 
operations on bytes, words, or doublewords packed into MMX registers (see Figure 9-4). For example, the PADDSW 
instruction adds 4 signed word integers from one source operand to 4 signed word integers in a second source 
operand and stores 4 word integer results in a destination operand. This SIMD technique speeds up software 
performance by allowing the same operation to be carried out on multiple data elements in parallel. MMX tech- 
nology supports parallel operations on byte, word, and doubleword data elements when contained in MMX regis- 
ters. 


The SIMD execution model supported in the MMX technology directly addresses the needs of modern media, 
communications, and graphics applications, which often use sophisticated algorithms that perform the same oper- 
ations on a large number of small data types (bytes, words, and doublewords). For example, most audio data is 
represented in 16-bit (word) quantities. The MMX instructions can operate on 4 words simultaneously with one 
instruction. Video and graphics information is commonly represented as palletized 8-bit (byte) quantities. In 
Figure 9-4, one MMX instruction operates on 8 bytes simultaneously. 


Source 1 X3 X2 x1 X0 


Source 2 


Destination X3 OP Y3 X2 OP Y2 X1 OP Y1 X0 OP YO 


Figure 9-4. SIMD Execution Model 


3.3 SATURATION AND WRAPAROUND MODES 


When performing integer arithmetic, an operation may result in an out-of-range condition, where the true result 
cannot be represented in the destination format. For example, when performing arithmetic on signed word inte- 
gers, positive overflow can occur when the true signed result is larger than 16 bits. 


The MMX technology provides three ways of handling out-of-range conditions: 


¢ Wraparound arithmetic — With wraparound arithmetic, a true out-of-range result is truncated (that is, the 
carry or overflow bit is ignored and only the least significant bits of the result are returned to the destination). 
Wraparound arithmetic is suitable for applications that control the range of operands to prevent out-of-range 
results. If the range of operands is not controlled, however, wraparound arithmetic can lead to large errors. For 
example, adding two large signed numbers can cause positive overflow and produce a negative result. 


* Signed saturation arithmetic — With signed saturation arithmetic, out-of-range results are limited to the 
representable range of signed integers for the integer size being operated on (see Table 9-1). For example, if 
positive overflow occurs when operating on signed word integers, the result is “saturated” to 7FFFH, which is 
the largest positive integer that can be represented in 16 bits; if negative overflow occurs, the result is 
saturated to 8000H. 


¢ Unsigned saturation arithmetic — With unsigned saturation arithmetic, out-of-range results are limited to 
the representable range of unsigned integers for the integer size. So, positive overflow when operating on 
unsigned byte integers results in FFH being returned and negative overflow results in OOH being returned. 
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Table 9-1. Data Range Limits for Saturation 


Data Type Lower Limit Upper Limit 
Hexadecimal Decimal Hexadecimal Decimal 
Signed Byte 80H -128 7FH 127 
Signed Word 8000H -32,768 7FFFH 32,767 
Unsigned Byte OOH 0 FFH 255 
Unsigned Word OO00H 0 FFFFH 65,535 


Saturation arithmetic provides an answer for many overflow situations. For example, in color calculations, satura- 
tion causes a color to remain pure black or pure white without allowing inversion. It also prevents wraparound arti- 
facts from entering into computations when range checking of source operands it not used. 


MMX instructions do not indicate overflow or underflow occurrence by generating exceptions or setting flags in the 
EFLAGS register. 


9.4 MMX INSTRUCTIONS 


The MMxX instruction set consists of 47 instructions, grouped into the following categories: 


Data transfer 

Arithmetic 

Comparison 

Conversion 

Unpacking 

Logical 

Shift 

Empty MMX state instruction (EMMS) 


Table 9-2 gives a summary of the instructions in the MMX instruction set. The following sections give a brief over- 
view of the instructions within each group. 


NOTES 


The MMxX instructions described in this chapter are those instructions that are available in an IA-32 
processor when CPUID.01H:EDX.MMX[bit 23] = 1. 


Section 10.4.4, “SSE 64-Bit SIMD Integer Instructions,” and Section 11.4.2, “SSE2 64-Bit and 128- 
Bit SIMD Integer Instructions,” list additional instructions included with SSE/SSE2 extensions that 
operate on the MMX registers but are not considered part of the MMX instruction set. 


Vol.1 9-5 


PROGRAMMING WITH INTEL® MMX™ TECHNOLOGY 


Table 9-2. MMX Instruction Set Summary 


Category Wraparound Signed Saturation Unsigned Saturation 
Arithmetic Addition PADDB, PADDW, PADDD__| PADDSB, PADDSW PADDUSB, PADDUSW 
PSUBB, PSUBW, PSUBD —_| PSUBSB, PSUBSW PSUBUSB, PSUBUSW 
Subtraction PMULL, PMULH 
PMADD 
Multiplication 
Multiply and Add 
Comparison Compare for Equal PCMPEQB, PCMPEQW, 
PCMPEQD 
PCMPGTPB, PCMPGTPW, 
Compare for Greater PCMPGTPD 
Than 
Conversion Pack PACKSSWB, PACKUSWB 
PACKSSDW 
Unpack Unpack High PUNPCKHBW, 
PUNPCKHWD, 
PUNPCKHDQ 
Unpack Low PUNPCKLBW, 
PUNPCKLWD, 
PUNPCKLDQ 
Packed Full Quadword 
Logical And PAND 
And Not PANDN 
Or POR 
Exclusive OR PXOR 
Shift Shift Left Logical PSLLW, PSLLD PSLLOQ 
Shift Right Logical PSRLW, PSRLD PSRLOQ 
Shift Right Arithmetic PSRAW, PSRAD 
Doubleword Transfers Quadword Transfers 
Data Transfer Register to Register MOVD MOVQ 
Load from Memory MOVD MOVQ 
Store to Memory MOVD MOVQ 
Empty MMX State EMMS 
9.4.1 Data Transfer Instructions 


The MOVD (Move 32 Bits) instruction transfers 32 bits of packed data from memory to an MMX register and vice 


versa; or from a general-purpose register to an MMX register and vice versa. 


The MOVQ (Move 64 Bits) instruction transfers 64 bits of packed data from memory to an MMX register and vice 


versa; or transfers data between MMxX registers. 


9.4.2 


data types. 


The PADDB/PADDW/PADDD (add packed integers) instructions and the PSUBB/PSUBW/ PSUBD (subtract packed 
integers) instructions add or subtract the corresponding signed or unsigned data elements of the source and desti- 
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nation operands in wraparound mode. These instructions operate on packed byte, word, and doubleword data 
types. 


The PADDSB/PADDSW (add packed signed integers with signed saturation) instructions and the PSUBSB/PSUBSW 
(subtract packed signed integers with signed saturation) instructions add or subtract the corresponding signed 
data elements of the source and destination operands and saturate the result to the limits of the signed data-type 
range. These instructions operate on packed byte and word data types. 


The PADDUSB/PADDUSW (add packed unsigned integers with unsigned saturation) instructions and the 
PSUBUSB/PSUBUSW (subtract packed unsigned integers with unsigned saturation) instructions add or subtract the 
corresponding unsigned data elements of the source and destination operands and saturate the result to the limits 
of the unsigned data-type range. These instructions operate on packed byte and word data types. 


The PMULHW (multiply packed signed integers and store high result) and PMULLW (multiply packed signed integers 
and store low result) instructions perform a signed multiply of the corresponding words of the source and destina- 
tion operands and write the high-order or low-order 16 bits of each of the results, respectively, to the destination 
operand. 


The PMADDWD (multiply and add packed integers) instruction computes the products of the corresponding signed 
words of the source and destination operands. The four intermediate 32-bit doubleword products are summed in 
pairs (high-order pair and low-order pair) to produce two 32-bit doubleword results. 


9.4.3 Comparison Instructions 


The PCMPEQB/PCMPEQW/PCMPEQD (compare packed data for equal) instructions and the 
PCMPGTB/PCMPGTW/PCMPGTD (compare packed signed integers for greater than) instructions compare the corre- 
sponding signed data elements (bytes, words, or doublewords) in the source and destination operands for equal to 
or greater than, respectively. 


These instructions generate a mask of ones or zeros which are written to the destination operand. Logical opera- 
tions can use the mask to select packed elements. This can be used to implement a packed conditional move oper- 
ation without a branch or a set of branch instructions. No flags in the EFLAGS register are affected. 


9.4.4 Conversion Instructions 


The PACKSSWEB (pack words into bytes with signed saturation) and PACKSSDW (pack doublewords into words with 
signed saturation) instructions convert signed words into signed bytes and signed doublewords into signed words, 
respectively, using signed saturation. 


PACKUSWEB (pack words into bytes with unsigned saturation) converts signed words into unsigned bytes, using 
unsigned saturation. 


9.4.5 Unpack Instructions 


The PUNPCKHBW/PUNPCKHWD/PUNPCKHDQ (unpack high-order data elements) instructions and the 
PUNPCKLBW/PUNPCKLWD/PUNPCKLDQ (unpack low-order data elements) instructions unpack bytes, words, or 
doublewords from the high- or low-order data elements of the source and destination operands and interleave 
them in the destination operand. By placing all Os in the source operand, these instructions can be used to convert 
byte integers to word integers, word integers to doubleword integers, or doubleword integers to quadword inte- 
gers. 


9.4.6 Logical Instructions 


PAND (bitwise logical AND), PANDN (bitwise logical AND NOT), POR (bitwise logical OR), and PXOR (bitwise logical 
exclusive OR) perform bitwise logical operations on the quadword source and destination operands. 
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9.4.7 Shift Instructions 


The logical shift left, logical shift right and arithmetic shift right instructions shift each element by a specified 
number of bit positions. 


The PSLLW/PSLLD/PSLLQ (shift packed data left logical) instructions and the PSRLW/PSRLD/PSRLQ (shift packed 
data right logical) instructions perform a logical left or right shift of the data elements and fill the empty high or low 
order bit positions with zeros. These instructions operate on packed words, doublewords, and quadwords. 


The PSRAW/PSRAD (shift packed data right arithmetic) instructions perform an arithmetic right shift, copying the 
sign bit for each data element into empty bit positions on the upper end of each data element. This instruction 
operates on packed words and doublewords. 


9.4.8 EMMS Instruction 


The EMMS instruction empties the MMX state by setting the tags in x87 FPU tag word to 11B, indicating empty 
registers. This instruction must be executed at the end of an MMX routine before calling other routines that can 
execute floating-point instructions. See Section 9.6.3, “Using the EMMS Instruction,” for more information on the 
use of this instruction. 


9.5 COMPATIBILITY WITH X87 FPU ARCHITECTURE 


The MMxX state is aliased to the x87 FPU state. No new states or modes have been added to IA-32 architecture to 
support the MMX technology. The same floating-point instructions that save and restore the x87 FPU state also 
handle the MMX state (for example, during context switching). 


MMX technology uses the same interface techniques between the x87 FPU and the operating system (primarily for 
task switching purposes). For more details, see Chapter 12, “Intel® MMX™ Technology System Programming,” in 
the Inte!® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. 


9.5.1 MMxX Instructions and the x87 FPU Tag Word 


After each MMX instruction, the entire x87 FPU tag word is set to valid (0OB). The EMMS instruction (empty MMX 
state) sets the entire x87 FPU tag word to empty (11B). 


Chapter 12, “Intel® MMX™ Technology System Programming,” in the Inte/® 64 and IA-32 Architectures Software 
Developer’s Manual, Volume 3A, provides additional information about the effects of x87 FPU and MMxX instructions 
on the x87 FPU tag word. For a description of the tag word, see Section 8.1.7, “x87 FPU Tag Word.” 


9.6 WRITING APPLICATIONS WITH MMX CODE 


The following sections give guidelines for writing application code that uses MMX technology. 


9.6.1 Checking for MMX Technology Support 


Before an application attempts to use the MMX technology, it should check that it is present on the processor. Check 
by following these steps: 


1. Check that the processor supports the CPUID instruction by attempting to execute the CPUID instruction. If the 
processor does not support the CPUID instruction, this will generate an invalid-opcode exception (#UD). 


2. Check that the processor supports the MMX technology 
(if CPUID.O1H:EDX.MMX[bit 23] = 1). 


3. Check that emulation of the x87 FPU is disabled (if CRO.EM[bit 2] = 0). 


If the processor attempts to execute an unsupported MM X instruction or attempts to execute an MMX instruction 
with CRO.EM[bit 2] set, this generates an invalid-opcode exception (#UD). 
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Example 9-1 illustrates how to use the CPUID instruction to detect the MMX technology. This example does not 
represent the entire CPUID sequence, but shows the portion used for detection of MMX technology. 


Example 9-1. Partial Routine for Detecting MMX Technology with the CPUID Instruction 


; identify existence of CPUID instruction 
ia ; identify Intel processor 
mov EAX,1 ; request for feature flags 


CPUID ; OFH, OA2H CPUID instruction 
test EDX, OO800000H Is IAMMX technology bit (Bit 23 of EDX) set? 
jnz ; MMX_Technology_Found 


9.6.2 Transitions Between x87 FPU and MMX Code 


Applications can contain both x87 FPU floating-point and MMX instructions. However, because the MMX registers 
are aliased to the x87 FPU register stack, care must be taken when making transitions between x87 FPU instruc- 
tions and MMxX instructions to prevent incoherent or unexpected results. 


When an MMx instruction (other than the EMMS instruction) is executed, the processor changes the x87 FPU state 
as follows: 


¢ The TOS (top of stack) value of the x87 FPU status word is set to 0. 
¢ The entire x87 FPU tag word is set to the valid state (OOB in all tag fields). 


¢ When an MMxX instruction writes to an MMX register, it writes ones (11B) to the exponent part of the corre- 
sponding floating-point register (bits 64 through 79). 


The net result of these actions is that any x87 FPU state prior to the execution of the MMX instruction is essentially 
lost. 


When an x87 FPU instruction is executed, the processor assumes that the current state of the x87 FPU register 
stack and control registers is valid and executes the instruction without any preparatory modifications to the x87 
FPU state. 


If the application contains both x87 FPU floating-point and MMX instructions, the following guidelines are recom- 
mended: 


¢ When transitioning between x87 FPU and MMX code, save the state of any x87 FPU data or control registers 
that need to be preserved for future use. The FSAVE and FXSAVE instructions save the entire x87 FPU state. 


¢ When transitioning between MMX and x87 FPU code, do the following: 


— Save any data in the MMX registers that needs to be preserved for future use. FSAVE and FXSAVE also save 
the state of MMX registers. 


— Execute the EMMS instruction to clear the MMX state from the x87 data and control registers. 


The following sections describe the use of the EMMS instruction and give additional guidelines for mixing x87 FPU 
and MMX code. 


9.6.3 Using the EMMS Instruction 


As described in Section 9.6.2, “Transitions Between x87 FPU and MMX Code,” when an MM X instruction executes, 
the x87 FPU tag word is marked valid (OOB). In this state, the execution of subsequent x87 FPU instructions may 
produce unexpected x87 FPU floating-point exceptions and/or incorrect results because the x87 FPU register stack 
appears to contain valid data. The EMMS instruction is provided to prevent this problem by marking the x87 FPU 
tag word as empty. 


The EMMS instruction should be used in each of the following cases: 


¢ When an application using the x87 FPU instructions calls an MMX technology library/DLL (use the EMMS 
instruction at the end of the MMX code). 
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¢ When an application using MMX instructions calls a x87 FPU floating-point library/DLL (use the EMMS 
instruction before calling the x87 FPU code). 


¢ When a switch is made between MMX code in a task or thread and other tasks or threads in cooperative 
operating systems, unless it is certain that more MMX instructions will be executed before any x87 FPU code. 


EMMS is not required when mixing MMX technology instructions with SSE/SSE2/SSE3 instructions (see Section 
11.6.7, “Interaction of SSE/SSE2 Instructions with x87 FPU and MMxX Instructions”). 


9.6.4 Mixing MMX and x87 FPU Instructions 


An application can contain both x87 FPU floating-point and MMX instructions. However, frequent transitions 
between MMX and x87 FPU instructions are not recommended, because they can degrade performance in some 
processor implementations. When mixing MMX code with x87 FPU code, follow these guidelines: 


° Keep the code in separate modules, procedures, or routines. 
* Do not rely on register contents across transitions between x87 FPU and MMX code modules. 


¢ When transitioning between MMX code and x87 FPU code, save the MMX register state (if it will be needed in 
the future) and execute an EMMS instruction to empty the MMxX state. 


¢ When transitioning between x87 FPU code and MMX code, save the x87 FPU state if it will be needed in the 
future. 


9.6.5 Interfacing with MMX Code 


MMX technology enables direct access to all the MMX registers. This means that all existing interface conventions 
that apply to the use of the processor’s general-purpose registers (EAX, EBX, etc.) also apply to the use of MMX 
registers. 


An efficient interface to MMX routines might pass parameters and return values through the MMX registers or 
through a combination of memory locations (via the stack) and MMX registers. Do not use the EMMS instruction or 
mix MMX and x87 FPU code when using to the MMX registers to pass parameters. 


If a high-level language that does not support the MMX data types directly is used, the MMX data types can be 
defined as a 64-bit structure containing packed data types. 


When implementing MMX instructions in high-level languages, other approaches can be taken, such as: 
¢ Passing parameters to an MMX routine by passing a pointer to a structure via the stack. 
* Returning a value from a function by returning a pointer to a structure. 


9.6.6 Using MMX Code in a Multitasking Operating System Environment 


An application needs to identify the nature of the multitasking operating system on which it runs. Each task retains 
its own state which must be saved when a task switch occurs. The processor state (context) consists of the 
general-purpose registers and the floating-point and MMX registers. 


Operating systems can be classified into two types: 
* Cooperative multitasking operating system 
¢ Preemptive multitasking operating system 


Cooperative multitasking operating systems do not save the FPU or MMX state when performing a context switch. 
Therefore, the application needs to save the relevant state before relinquishing direct or indirect control to the 
operating system. 


Preemptive multitasking operating systems are responsible for saving and restoring the FPU and MMX state when 
performing a context switch. Therefore, the application does not have to save or restore the FPU and MMxX state. 
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9.6.7 Exception Handling in MMX Code 


MMX instructions generate the same type of memory-access exceptions as other IA-32 instructions (page fault, 
segment not present, and limit violations). Existing exception handlers do not have to be modified to handle these 
types of exceptions for MMX code. 


Unless there is a pending floating-point exception, MMX instructions do not generate numeric exceptions. There- 
fore, there is no need to modify existing exception handlers or add new ones to handle numeric exceptions. 


If a floating-point exception is pending, the subsequent MMX instruction generates a numeric error exception 
(interrupt 16 and/or assertion of the FERR# pin). The MMX instruction resumes execution upon return from the 
exception handler. 


9.6.8 Register Mapping 


MMxX registers and their tags are mapped to physical locations of the floating-point registers and their tags. 
Register aliasing and mapping is described in more detail in Chapter 12, “Intel® MMX"' Technology System 
Programming,” in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. 


9.6.9 Effect of Instruction Prefixes on MMX Instructions 


Table 9-3 describes the effect of instruction prefixes on MMX instructions. Unpredictable behavior can range from 
being treated as a reserved operation on one generation of IA-32 processors to generating an invalid opcode 
exception on another generation of processors. 

Table 9-3. Effect of Prefixes on MMX Instructions 
Prefix Type Effect on MMX Instructions 


Address Size Prefix (67H) Affects instructions with a memory operand. 


Reserved for instructions without a memory operand and may result in 
unpredictable behavior. 


Operand Size (66H) Reserved and may result in unpredictable behavior. 

Segment Override (2E€H, 36H, 3EH, 26H, 64H, | Affects instructions with a memory operand. 

65H) Reserved for instructions without a memory operand and may result in 
unpredictable behavior. 

Repeat Prefix (F3H) Reserved and may result in unpredictable behavior. 

Repeat NE Prefix(F2H) Reserved and may result in unpredictable behavior. 

Lock Prefix (FOH) Reserved; generates invalid opcode exception (HUD). 

Branch Hint Prefixes (2EH and 3EH) Reserved and may result in unpredictable behavior. 


See “Instruction Prefixes” in Chapter 2, “Instruction Format,” of the Inte/® 64 and IA-32 Architectures Software 
Developer’s Manual, Volume 2A, for a description of the instruction prefixes. 
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CHAPTER 10 
PROGRAMMING WITH INTEL® 
STREAMING SIMD EXTENSIONS (INTEL® SSE) 


The streaming SIMD extensions (SSE) were introduced into the IA-32 architecture in the Pentium III processor 
family. These extensions enhance the performance of IA-32 processors for advanced 2-D and 3-D graphics, motion 
video, image processing, speech recognition, audio synthesis, telephony, and video conferencing. 


This chapter describes SSE. Chapter 11, “Programming with Intel® Streaming SIMD Extensions 2 (Intel® SSE2),” 
provides information to assist in writing application programs that use SSE2 extensions. Chapter 12, “Programming 
with Intel® SSE3, SSSE3, Intel® SSE4 and Intel® AESNI,” provides this information for SSE3 extensions. 


10.1 OVERVIEW OF SSE EXTENSIONS 


Intel MMX technology introduced single-instruction multiple-data (SIMD) capability into the IA-32 architecture, 
with the 64-bit MMX registers, 64-bit packed integer data types, and instructions that allowed SIMD operations to 
be performed on packed integers. SSE extensions expand the SIMD execution model by adding facilities for 
handling packed and scalar single-precision floating-point values contained in 128-bit registers. 


If CPUID.O1H:EDX.SSE[bit 25] = 1, SSE extensions are present. 


SSE extensions add the following features to the IA-32 architecture, while maintaining backward compatibility with 
all existing IA-32 processors, applications and operating systems. 


° Eight 128-bit data registers (called XMM registers) in non-64-bit modes; sixteen XMM registers are available in 
64-bit mode. 


° The 32-bit MXCSR register, which provides control and status bits for operations performed on XMM registers. 


° The 128-bit packed single-precision floating-point data type (four IEEE single-precision floating-point values 
packed into a double quadword). 


¢ Instructions that perform SIMD operations on single-precision floating-point values and that extend SIMD 
operations that can be performed on integers: 


— 128-bit Packed and scalar single-precision floating-point instructions that operate on data located in MMX 
registers 


— 64-bit SIMD integer instructions that support additional operations on packed integer operands located in 
MMX registers 


° Instructions that save and restore the state of the MXCSR register. 


¢ Instructions that support explicit prefetching of data, control of the cacheability of data, and control the 
ordering of store operations. 


¢ Extensions to the CPUID instruction. 
These features extend the IA-32 architecture’s SIMD programming model in four important ways: 


¢ The ability to perform SIMD operations on four packed single-precision floating-point values enhances the 
performance of IA-32 processors for advanced media and communications applications that use computation- 
intensive algorithms to perform repetitive operations on large arrays of simple, native data elements. 

¢ The ability to perform SIMD single-precision floating-point operations in XMM registers and SIMD integer 
operations in MMX registers provides greater flexibility and throughput for executing applications that operate 
on large arrays of floating-point and integer data. 

* Cache control instructions provide the ability to stream data in and out of XMM registers without polluting the 
caches and the ability to prefetch data to selected cache levels before it is actually used. Applications that 
require regular access to large amounts of data benefit from these prefetching and streaming store capabilities. 

° The SFENCE (store fence) instruction provides greater control over the ordering of store operations when using 
weakly-ordered memory types. 
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SSE extensions are fully compatible with all software written for IA-32 processors. All existing software continues 
to run correctly, without modification, on processors that incorporate SSE extensions. Enhancements to CPUID 
permit detection of SSE extensions. SSE extensions are accessible from all IA-32 execution modes: protected 
mode, real address mode, and virtual-8086 mode. 


The following sections of this chapter describe the programming environment for SSE extensions, including: XMM 
registers, the packed single-precision floating-point data type, and SSE instructions. For additional information, 
see: 


® Section 11.6, “Writing Applications with SSE/SSE2 Extensions”. 


® Section 11.5, “SSE, SSE2, and SSE3 Exceptions,” describes the exceptions that can be generated with 
SSE/SSE2/SSE3 instructions. 


° Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A & 2B, provide a detailed 
description of these instructions. 


° Chapter 13, “System Programming for Instruction Set Extensions and Processor Extended States,” in the 
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, gives guidelines for integrating 
these extensions into an operating-system environment. 


10.2 SSE PROGRAMMING ENVIRONMENT 


Figure 10-1 shows the execution environment for the SSE extensions. All SSE instructions operate on the XMM 
registers, MMX registers, and/or memory as follows: 


¢ XMM registers — These eight registers (see Figure 10-2 and Section 10.2.2, “XMM Registers”) are used to 
operate on packed or scalar single-precision floating-point data. Scalar operations are operations performed on 
individual (unpacked) single-precision floating-point values stored in the low doubleword of an XMM register. 
XMM registers are referenced by the names XMMO through XMM7. 


Address Space 
32 
XMM Registers en 
Eight 128-Bit 
MXCSR Register 32 Bits 
MMX Registers 
Eight 64-Bit 
General-Purpose 
Registers 
Eight 32-Bit 

0 

EFLAGS Register 32 Bits 


Figure 10-1. SSE Execution Environment 


* MXCSR register — This 32-bit register (see Figure 10-3 and Section 10.2.3, “MXCSR Control and Status 
Register”) provides status and control bits used in SIMD floating-point operations. 


° MMxX registers — These eight registers (see Figure 9-2) are used to perform operations on 64-bit packed 
integer data. They are also used to hold operands for some operations performed between the MMX and XMM 
registers. MMX registers are referenced by the names MMO through MM7. 


¢ General-purpose registers — The eight general-purpose registers (see Figure 3-5) are used along with the 
existing IA-32 addressing modes to address operands in memory. (MMX and XMM registers cannot be used to 
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address memory). The general-purpose registers are also used to hold operands for some SSE instructions and 
are referenced as EAX, EBX, ECX, EDX, EBP, ESI, EDI, and ESP. 


° EFLAGS register — This 32-bit register (see Figure 3-8) is used to record result of some compare operations. 


10.2.1 SSE in 64-Bit Mode and Compatibility Mode 


In compatibility mode, SSE extensions function like they do in protected mode. In 64-bit mode, eight additional 
XMM registers are accessible. Registers XMM8-XMM15 are accessed by using REX prefixes. Memory operands are 
specified using the ModR/M, SIB encoding described in Section 3.7.5. 


Some SSE instructions may be used to operate on general-purpose registers. Use the REX.W prefix to access 64- 
bit general-purpose registers. Note that if a REX prefix is used when it has no meaning, the prefix is ignored. 


10.2.2 XMM Registers 


Eight 128-bit XMM data registers were introduced into the IA-32 architecture with SSE extensions (see 

Figure 10-2). These registers can be accessed directly using the names XMMO to XMM7; and they can be accessed 
independently from the x87 FPU and MMX registers and the general-purpose registers (that is, they are not aliased 
to any other of the processor’s registers). 


127 0 
XMM7 


XMM6 


XMM5 


XMM4 


XMM3 


XMM2 


XMM1 


XMMO 


Figure 10-2. XMM Registers 


SSE instructions use the XMM registers only to operate on packed single-precision floating-point operands. SSE2 
extensions expand the functions of the XMM registers to operand on packed or scalar double-precision floating- 
point operands and packed integer operands (see Section 11.2, “SSE2 Programming Environment,” and Section 
12.1, “Programming Environment and Data types”). 


XMM registers can only be used to perform calculations on data; they cannot be used to address memory. 
Addressing memory is accomplished by using the general-purpose registers. 


Data can be loaded into XMM registers or written from the registers to memory in 32-bit, 64-bit, and 128-bit incre- 
ments. When storing the entire contents of an XMM register in memory (128-bit store), the data is stored in 16 
consecutive bytes, with the low-order byte of the register being stored in the first byte in memory. 


10.2.3. MXCSR Control and Status Register 


The 32-bit MXCSR register (see Figure 10-3) contains control and status information for SSE, SSE2, and SSE3 
SIMD floating-point operations. This register contains: 


¢ flag and mask bits for SIMD floating-point exceptions 
* rounding control field for SIMD floating-point operations 


Vol. 1 10-3 


PROGRAMMING WITH INTEL® STREAMING SIMD EXTENSIONS (INTEL® SSE) 


¢  flush-to-zero flag that provides a means of controlling underflow conditions on SIMD floating-point operations 
¢  denormals-are-zeros flag that controls how SIMD floating-point instructions handle denormal source operands 


The contents of this register can be loaded from memory with the LDMXCSR and FXRSTOR instructions and stored 
in memory with STMXCSR and FXSAVE. 


Bits 16 through 31 of the MXCSR register are reserved and are cleared on a power-up or reset of the processor; 
attempting to write a non-zero value to these bits, using either the FXRSTOR or LDMXCSR instructions, will result 
in a general-protection exception (#GP) being generated. 


31 161514131211109 876543210 


NAT 


R |Pfujo}z}p] 1/2/P|ujojzjp 
Reserved C |M/M)M/MjM|M|>/E/E)E;E/ E/E 


Flush to Zero 
Rounding Control 
Precision Mask 
Underflow Mask 
Overflow Mask 
Divide-by-Zero Mask 
Denormal Operation Mask 
Invalid Operation Mask 
Denormals Are Zeros* 
Precision Flag 
Underflow Flag 
Overflow Flag 
Divide-by-Zero Flag 
Denormal Flag 
Invalid Operation Flag 


* The denormals-are-zeros flag was introduced in the Pentium 4 and Intel Xeon processor. 


Figure 10-3. MXCSR Control/Status Register 


10.2.3.1 SIMD Floating-Point Mask and Flag Bits 


Bits 0 through 5 of the MXCSR register indicate whether a SIMD floating-point exception has been detected. They 
are “sticky” flags. That is, after a flag is set, it remains set until explicitly cleared. To clear these flags, use the 
LDMXCSR or the FXRSTOR instruction to write zeroes to them. 


Bits 7 through 12 provide individual mask bits for the SIMD floating-point exceptions. An exception type is masked 
if the corresponding mask bit is set, and it is unmasked if the bit is clear. These mask bits are set upon a power-up 
or reset. This causes all SIMD floating-point exceptions to be initially masked. 


If LDMXCSR or FXRSTOR clears a mask bit and sets the corresponding exception flag bit, a SIMD floating-point 
exception will not be generated as a result of this change. The unmasked exception will be generated only upon the 
execution of the next SSE/SSE2/SSE3 instruction that detects the unmasked exception condition. 


For more information about the use of the SIMD floating-point exception mask and flag bits, see Section 11.5, 
“SSE, SSE2, and SSE3 Exceptions,” and Section 12.8, “SSE3/SSSE3 And SSE4 Exceptions.” 


10.2.3.2 SIMD Floating-Point Rounding Control Field 


Bits 13 and 14 of the MXCSR register (the rounding control [RC] field) control how the results of SIMD floating-point 
instructions are rounded. See Section 4.8.4, “Rounding,” for a description of the function and encoding of the 
rounding control bits. 


10.2.3.3. Flush-To-Zero 


Bit 15 (FTZ) of the MXCSR register enables the flush-to-zero mode, which controls the masked response to a SIMD 
floating-point underflow condition. When the underflow exception is masked and the flush-to-zero mode is 
enabled, the processor performs the following operations when it detects a floating-point underflow condition. 
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¢ Returns a zero result with the sign of the true result. 
* Sets the precision and underflow exception flags. 
If the underflow exception is not masked, the flush-to-zero bit is ignored. 


The flush-to-zero mode is not compatible with IEEE Standard 754. The IEEE-mandated masked response to under- 
flow is to deliver the denormalized result (see Section 4.8.3.2, “Normalized and Denormalized Finite Numbers”). 
The flush-to-zero mode is provided primarily for performance reasons. At the cost of a slight precision loss, faster 
execution can be achieved for applications where underflows are common and rounding the underflow result to 
zero can be tolerated. 


The flush-to-zero bit is cleared upon a power-up or reset of the processor, disabling the flush-to-zero mode. 


10.2.3.4 Denormals-Are-Zeros 


Bit 6 (DAZ) of the MXCSR register enables the denormals-are-zeros mode, which controls the processor’s response 
to a SIMD floating-point denormal operand condition. When the denormals-are-zeros flag is set, the processor 
converts all denormal source operands to a zero with the sign of the original operand before performing any 
computations on them. The processor does not set the denormal-operand exception flag (DE), regardless of the 
setting of the denormal-operand exception mask bit (DM); and it does not generate a denormal-operand exception 
if the exception is unmasked. 


The denormals-are-zeros mode is not compatible with IEEE Standard 754 (see Section 4.8.3.2, “Normalized and 
Denormalized Finite Numbers”). The denormals-are-zeros mode is provided to improve processor performance for 
applications such as streaming media processing, where rounding a denormal operand to zero does not appre- 
ciably affect the quality of the processed data. 


The denormals-are-zeros flag is cleared upon a power-up or reset of the processor, disabling the denormals-are- 
zeros mode. 


The denormals-are-zeros mode was introduced in the Pentium 4 and Intel Xeon processor with the SSE2 exten- 
sions; however, it is fully compatible with the SSE SIMD floating-point instructions (that is, the denormals-are- 
zeros flag affects the operation of the SSE SIMD floating-point instructions). In earlier IA-32 processors and in 
some models of the Pentium 4 processor, this flag (bit 6) is reserved. See Section 11.6.3, “Checking for the DAZ 
Flag in the MXCSR Register,” for instructions for detecting the availability of this feature. 


Attempting to set bit 6 of the MXCSR register on processors that do not support the DAZ flag will cause a general- 
protection exception (#GP). See Section 11.6.6, “Guidelines for Writing to the MXCSR Register,” for instructions for 
preventing such general-protection exceptions by using the MXCSR_MASK value returned by the FXSAVE instruc- 
tion. 


10.2.4 Compatibility of SSE Extensions with SSE2/SSE3/MMX and the x87 FPU 


The state (XMM registers and MXCSR register) introduced into the IA-32 execution environment with the SSE 
extensions is shared with SSE2 and SSE3 extensions. SSE/SSE2/SSE3 instructions are fully compatible; they can 
be executed together in the same instruction stream with no need to save state when switching between instruc- 
tion sets. 


XMM registers are independent of the x87 FPU and MMX registers, so SSE/SSE2/SSE3 operations performed on the 
XMM registers can be performed in parallel with operations on the x87 FPU and MMX registers (see Section 11.6.7, 
“Interaction of SSE/SSE2 Instructions with x87 FPU and MMxX Instructions”). 


The FXSAVE and FXRSTOR instructions save and restore the SSE/SSE2/SSE3 states along with the x87 FPU and 
MMX state. 


10.3. SSEDATA TYPES 


SSE extensions introduced one data type, the 128-bit packed single-precision floating-point data type, to the IA- 
32 architecture (see Figure 10-4). This data type consists of four IEEE 32-bit single-precision floating-point values 
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packed into a double quadword. (See Figure 4-3 for the layout of a single-precision floating-point value; refer to 
Section 4.2.2, “Floating-Point Data Types,” for a detailed description of the single-precision floating-point format.) 


PT Frcating Point aves 
Floating-Point Values 


127 96 95 64 63 32 31 0 


Figure 10-4. 128-Bit Packed Single-Precision Floating-Point Data Type 


This 128-bit packed single-precision floating-point data type is operated on in the XMM registers or in memory. 
Conversion instructions are provided to convert two packed single-precision floating-point values into two packed 
doubleword integers or a scalar single-precision floating-point value into a doubleword integer (see Figure 11-8). 


SSE extensions provide conversion instructions between XMM registers and MMX registers, and between XMM 
registers and general-purpose bit registers. See Figure 11-8. 


The address of a 128-bit packed memory operand must be aligned on a 16-byte boundary, except in the following 
cases: 


¢ The MOVUPS instruction supports unaligned accesses. 
¢* Scalar instructions that use a 4-byte memory operand that is not subject to alignment requirements. 
Figure 4-2 shows the byte order of 128-bit (double quadword) data types in memory. 


10.4 SSE INSTRUCTION SET 


SSE instructions are divided into four functional groups 

¢ Packed and scalar single-precision floating-point instructions 

° 64-bit SIMD integer instructions 

° State management instructions 

* Cacheability control, prefetch, and memory ordering instructions 

The following sections give an overview of each of the instructions in these groups. 


10.4.1. SSE Packed and Scalar Floating-Point Instructions 


The packed and scalar single-precision floating-point instructions are divided into the following subgroups: 
¢ Data movement instructions 

e  =6Arithmetic instructions 

® Logical instructions 

* Comparison instructions 

¢ Shuffle instructions 

* Conversion instructions 


The packed single-precision floating-point instructions perform SIMD operations on packed single-precision 
floating-point operands (see Figure 10-5). Each source operand contains four single-precision floating-point 
values, and the destination operand contains the results of the operation (OP) performed in parallel on the corre- 
sponding values (XO and YO, Xi and Y1, X2 and Y2, and X3 and Y3) in each operand. 
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X3 X2 x1 X0 
Y3 Y2 Y1 YO 
X3 OP Y3 X2 OP Y2 X1 OP Y1 X0 OP YO 


Figure 10-5. Packed Single-Precision Floating-Point Operation 


The scalar single-precision floating-point instructions operate on the low (least significant) doublewords of the two 
source operands (XO and YO); see Figure 10-6. The three most significant doublewords (X1, X2, and X3) of the first 
source operand are passed through to the destination. The scalar operations are similar to the floating-point oper- 
ations performed in the x87 FPU data registers with the precision control field in the x87 FPU control word set for 
single precision (24-bit significand), except that x87 stack operations use a 15-bit exponent range for the result, 
while SSE operations use an 8-bit exponent range. 


x3 x2 x1 xo 
Y3 ¥2 Y1 Yo 

y y Y 

x3 x2 x1 X0 OP YO 


Figure 10-6. Scalar Single-Precision Floating-Point Operation 


10.4.1.1 SSE Data Movement Instructions 


SSE data movement instructions move single-precision floating-point data between XMM registers and between an 
XMM register and memory. 


The MOVAPS (move aligned packed single-precision floating-point values) instruction transfers a double quadword 
operand containing four packed single-precision floating-point values from memory to an XMM register and vice 
versa, or between XMM registers. The memory address must be aligned to a 16-byte boundary; otherwise, a 
general-protection exception (#GP) is generated. 


The MOVUPS (move unaligned packed single-precision, floating-point) instruction performs the same operations as 
the MOVAPS instruction, except that 16-byte alignment of a memory address is not required. 


The MOVSS (move scalar single-precision floating-point) instruction transfers a 32-bit single-precision floating- 
point operand from memory to the low doubleword of an XMM register and vice versa, or between XMM registers. 


The MOVLPS (move low packed single-precision floating-point) instruction moves two packed single-precision 
floating-point values from memory to the low quadword of an XMM register and vice versa. The high quadword of 
the register is left unchanged. 
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The MOVHPS (move high packed single-precision floating-point) instruction moves two packed single-precision 
floating-point values from memory to the high quadword of an XMM register and vice versa. The low quadword of 
the register is left unchanged. 


The MOVLHPS (move packed single-precision floating-point low to high) instruction moves two packed single-preci- 
sion floating-point values from the low quadword of the source XMM register into the high quadword of the desti- 
nation XMM register. The low quadword of the destination register is left unchanged. 


The MOVHLPS (move packed single-precision floating-point high to low) instruction moves two packed single-preci- 
sion floating-point values from the high quadword of the source XMM register into the low quadword of the desti- 
nation XMM register. The high quadword of the destination register is left unchanged. 


The MOVMSKPS (move packed single-precision floating-point mask) instruction transfers the most significant bit of 
each of the four packed single-precision floating-point numbers in an XMM register to a general-purpose register. 
This 4-bit value can then be used as a condition to perform branching. 


10.4.1.2 SSE Arithmetic Instructions 


SSE arithmetic instructions perform addition, subtraction, multiply, divide, reciprocal, square root, reciprocal of 
square root, and maximum/minimum operations on packed and scalar single-precision floating-point values. 


The ADDPS (add packed single-precision floating-point values) and SUBPS (subtract packed single-precision 
floating-point values) instructions add and subtract, respectively, two packed single-precision floating-point oper- 
ands. 


The ADDSS (add scalar single-precision floating-point values) and SUBSS (subtract scalar single-precision floating- 
point values) instructions add and subtract, respectively, the low single-precision floating-point values of two oper- 
ands and store the result in the low doubleword of the destination operand. 


The MULPS (multiply packed single-precision floating-point values) instruction multiplies two packed single-preci- 
sion floating-point operands. 


The MULSS (multiply scalar single-precision floating-point values) instruction multiplies the low single-precision 
floating-point values of two operands and stores the result in the low doubleword of the destination operand. 


The DIVPS (divide packed, single-precision floating-point values) instruction divides two packed single-precision 
floating-point operands. 


The DIVSS (divide scalar single-precision floating-point values) instruction divides the low single-precision floating- 
point values of two operands and stores the result in the low doubleword of the destination operand. 


The RCPPS (compute reciprocals of packed single-precision floating-point values) instruction computes the approx- 
imate reciprocals of values in a packed single-precision floating-point operand. 


The RCPSS (compute reciprocal of scalar single-precision floating-point values) instruction computes the approxi- 
mate reciprocal of the low single-precision floating-point value in the source operand and stores the result in the 
low doubleword of the destination operand. 


The SQRTPS (compute square roots of packed single-precision floating-point values) instruction computes the 
square roots of the values in a packed single-precision floating-point operand. 


The SQRTSS (compute square root of scalar single-precision floating-point values) instruction computes the square 
root of the low single-precision floating-point value in the source operand and stores the result in the low double- 
word of the destination operand. 


The RSQRTPS (compute reciprocals of square roots of packed single-precision floating-point values) instruction 
computes the approximate reciprocals of the square roots of the values in a packed single-precision floating-point 
operand. 


The RSQRTSS (reciprocal of square root of scalar single-precision floating-point value) instruction computes the 
approximate reciprocal of the square root of the low single-precision floating-point value in the source operand and 
stores the result in the low doubleword of the destination operand. 


The MAXPS (return maximum of packed single-precision floating-point values) instruction compares the corre- 
sponding values from two packed single-precision floating-point operands and returns the numerically greater 
value from each comparison to the destination operand. 
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The MAXSS (return maximum of scalar single-precision floating-point values) instruction compares the low values 
from two packed single-precision floating-point operands and returns the numerically greater value from the 
comparison to the low doubleword of the destination operand. 


The MINPS (return minimum of packed single-precision floating-point values) instruction compares the corre- 
sponding values from two packed single-precision floating-point operands and returns the numerically lesser value 
from each comparison to the destination operand. 


The MINSS (return minimum of scalar single-precision floating-point values) instruction compares the low values 
from two packed single-precision floating-point operands and returns the numerically lesser value from the 
comparison to the low doubleword of the destination operand. 


10.4.2 SSE Logical Instructions 


SSE logical instructions perform AND, AND NOT, OR, and XOR operations on packed single-precision floating-point 
values. 


The ANDPS (bitwise logical AND of packed single-precision floating-point values) instruction returns the logical 
AND of two packed single-precision floating-point operands. 


The ANDNPS (bitwise logical AND NOT of packed single-precision, floating-point values) instruction returns the 
logical AND NOT of two packed single-precision floating-point operands. 


The ORPS (bitwise logical OR of packed single-precision, floating-point values) instruction returns the logical OR of 
two packed single-precision floating-point operands. 


The XORPS (bitwise logical XOR of packed single-precision, floating-point values) instruction returns the logical 
XOR of two packed single-precision floating-point operands. 


10.4.2.1 SSE Comparison Instructions 


The compare instructions compare packed and scalar single-precision floating-point values and return the results 
of the comparison either to the destination operand or to the EFLAGS register. 


The CMPPS (compare packed single-precision floating-point values) instruction compares the corresponding values 
from two packed single-precision floating-point operands, using an immediate operand as a predicate, and returns 
a 32-bit mask result of all 1s or all Os for each comparison to the destination operand. The value of the immediate 
operand allows the selection of any of 8 compare conditions: equal, less than, less than equal, unordered, not 
equal, not less than, not less than or equal, or ordered. 


The CMPSS (compare scalar single-precision, floating-point values) instruction compares the low values from two 
packed single-precision floating-point operands, using an immediate operand as a predicate, and returns a 32-bit 
mask result of all 1s or all Os for the comparison to the low doubleword of the destination operand. The immediate 
operand selects the compare conditions as with the CMPPS instruction. 


The COMISS (compare scalar single-precision floating-point values and set EFLAGS) and UCOMISS (unordered 
compare scalar single-precision floating-point values and set EFLAGS) instructions compare the low values of two 
packed single-precision floating-point operands and set the ZF, PF, and CF flags in the EFLAGS register to show the 
result (greater than, less than, equal, or unordered). These two instructions differ as follows: the COMISS instruc- 
tion signals a floating-point invalid-operation (#1) exception when a source operand is either a QNaN or an SNaN; 
the UCOMISS instruction only signals an invalid-operation exception when a source operand is an SNaN. 


10.4.2.2 SSE Shuffle and Unpack Instructions 


SSE shuffle and unpack instructions shuffle or interleave the contents of two packed single-precision floating-point 
values and store the results in the destination operand. 


The SHUFPS (shuffle packed single-precision floating-point values) instruction places any two of the four packed 
single-precision floating-point values from the destination operand into the two low-order doublewords of the 
destination operand, and places any two of the four packed single-precision floating-point values from the source 
operand in the two high-order doublewords of the destination operand (see Figure 10-7). By using the same 
register for the source and destination operands, the SHUFPS instruction can shuffle four single-precision floating- 
point values into any order. 
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DEST X3 X2 x1 X0 
SRC Y3 Y2 Y1 YO 
DEST Y3... YO Y3... YO X3 ... XO X3 ... XO 


Figure 10-7. SHUFPS Instruction, Packed Shuffle Operation 


The UNPCKHPS (unpack and interleave high packed single-precision floating-point values) instruction performs an 
interleaved unpack of the high-order single-precision floating-point values from the source and destination oper- 
ands and stores the result in the destination operand (see Figure 10-8). 


DEST X3 X2 x1 XO 
SRC Y3 Y1 YO 
DEST Y3 X3 Y2 X2 


Figure 10-8. UNPCKHPS Instruction, High Unpack and Interleave Operation 


The UNPCKLPS (unpack and interleave low packed single-precision floating-point values) instruction performs an 
interleaved unpack of the low-order single-precision floating-point values from the source and destination oper- 
ands and stores the result in the destination operand (see Figure 10-9). 


DEST X3 X2 x1 X0 
SRC Y3 Y2 Y1 YO 

Y 
DEST Y1 x1 YO X0 


Figure 10-9. UNPCKLPS Instruction, Low Unpack and Interleave Operation 
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10.4.3. SSE Conversion Instructions 


SSE conversion instructions (see Figure 11-8) support packed and scalar conversions between single-precision 
floating-point and doubleword integer formats. 


The CVTPI2PS (convert packed doubleword integers to packed single-precision floating-point values) instruction 
converts two packed signed doubleword integers into two packed single-precision floating-point values. When the 
conversion is inexact, the result is rounded according to the rounding mode selected in the MXCSR register. 


The CVTSI2SS (convert doubleword integer to scalar single-precision floating-point value) instruction converts a 
signed doubleword integer into a single-precision floating-point value. When the conversion is inexact, the result is 
rounded according to the rounding mode selected in the MXCSR register. 


The CVTPS2PI (convert packed single-precision floating-point values to packed doubleword integers) instruction 
converts two packed single-precision floating-point values into two packed signed doubleword integers. When the 
conversion is inexact, the result is rounded according to the rounding mode selected in the MXCSR register. The 
CVTTPS2PI (convert with truncation packed single-precision floating-point values to packed doubleword integers) 
instruction is similar to the CVTPS2PI instruction, except that truncation is used to round a source value to an 
integer value (see Section 4.8.4.2, “Truncation with SSE and SSE2 Conversion Instructions”). 


The CVTSS2SI (convert scalar single-precision floating-point value to doubleword integer) instruction converts a 
single-precision floating-point value into a signed doubleword integer. When the conversion is inexact, the result is 
rounded according to the rounding mode selected in the MXCSR register. The CVTTSS2SI (convert with truncation 
scalar single-precision floating-point value to doubleword integer) instruction is similar to the CVTSS2SI instruc- 
tion, except that truncation is used to round the source value to an integer value (see Section 4.8.4.2, “Truncation 
with SSE and SSE2 Conversion Instructions”). 


10.4.4 SSE 64-Bit SIMD Integer Instructions 


SSE extensions add the following 64-bit packed integer instructions to the IA-32 architecture. These instructions 
operate on data in MMX registers and 64-bit memory locations. 


NOTE 


When SSE2 extensions are present in an IA-32 processor, these instructions are extended to 
operate on 128-bit operands in XMM registers and 128-bit memory locations. 


The PAVGB (compute average of packed unsigned byte integers) and PAVGW (compute average of packed 
unsigned word integers) instructions compute a SIMD average of two packed unsigned byte or word integer oper- 
ands, respectively. For each corresponding pair of data elements in the packed source operands, the elements are 
added together, a 1 is added to the temporary sum, and that result is shifted right one bit position. 


The PEXTRW (extract word) instruction copies a selected word from an MMxX register into a general-purpose 
register. 


The PINSRW (insert word) instruction copies a word from a general-purpose register or from memory into a 
selected word location in an MMX register. 


The PMAXUB (maximum of packed unsigned byte integers) instruction compares the corresponding unsigned byte 
integers in two packed operands and returns the greater of each comparison to the destination operand. 


The PMINUB (minimum of packed unsigned byte integers) instruction compares the corresponding unsigned byte 
integers in two packed operands and returns the lesser of each comparison to the destination operand. 


The PMAXSW (maximum of packed signed word integers) instruction compares the corresponding signed word 
integers in two packed operands and returns the greater of each comparison to the destination operand. 


The PMINSW (minimum of packed signed word integers) instruction compares the corresponding signed word inte- 
gers in two packed operands and returns the lesser of each comparison to the destination operand. 


The PMOVMSKB (move byte mask) instruction creates an 8-bit mask from the packed byte integers in an MMX 
register and stores the result in the low byte of a general-purpose register. The mask contains the most significant 
bit of each byte in the MMX register. (When operating on 128-bit operands, a 16-bit mask is created.) 
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The PMULHUW (multiply packed unsigned word integers and store high result) instruction performs a SIMD 
unsigned multiply of the words in the two source operands and returns the high word of each result to an MMX 
register. 


The PSADBW (compute sum of absolute differences) instruction computes the SIMD absolute differences of the 
corresponding unsigned byte integers in two source operands, sums the differences, and stores the sum in the low 
word of the destination operand. 


The PSHUFW (shuffle packed word integers) instruction shuffles the words in the source operand according to the 
order specified by an 8-bit immediate operand and returns the result to the destination operand. 


10.4.5 MXCSR State Management Instructions 


The MXCSR state management instructions (LDMXCSR and STMXCSR) load and save the state of the MKCSR 
register, respectively. The LDMXCSR instruction loads the MXCSR register from memory, while the STMXCSR 
instruction stores the contents of the register to memory. 


10.4.6 Cacheability Control, Prefetch, and Memory Ordering Instructions 


SSE extensions introduce several new instructions to give programs more control over the caching of data. They 
also introduces the PREFETCHA instructions, which provide the ability to prefetch data to a specified cache level, 
and the SFENCE instruction, which enforces program ordering on stores. These instructions are described in the 
following sections. 


10.4.6.1 Cacheability Control Instructions 


The following three instructions enable data from the MMX and XMM registers to be stored to memory using a non- 
temporal hint. The non-temporal hint directs the processor to store the data to memory without writing the data 
into the cache hierarchy. See Section 10.4.6.2, “Caching of Temporal vs. Non-Temporal Data,” for information 
about non-temporal stores and hints. 


The MOVNTQ (store quadword using non-temporal hint) instruction stores packed integer data from an MMX 
register to memory, using a non-temporal hint. 


The MOVNTPS (store packed single-precision floating-point values using non-temporal hint) instruction stores 
packed floating-point data from an XMM register to memory, using a non-temporal hint. 


The MASKMOVQ (store selected bytes of quadword) instruction stores selected byte integers from an MMX register 
to memory, using a byte mask to selectively write the individual bytes. This instruction also uses a non-temporal 
hint. 


10.4.6.2 Caching of Temporal vs. Non-Temporal Data 


Data referenced by a program can be temporal (data will be used again) or non-temporal (data will be referenced 
once and not reused in the immediate future). For example, program code is generally temporal, whereas, multi- 
media data, such as the display list in a 3-D graphics application, is often non-temporal. To make efficient use of 
the processor’s caches, it is generally desirable to cache temporal data and not cache non-temporal data. Over- 
loading the processor’s caches with non-temporal data is sometimes referred to as “polluting the caches.” The SSE 
and SSE2 cacheability control instructions enable a program to write non-temporal data to memory in a manner 
that minimizes pollution of caches. 


These SSE and SSE2 non-temporal store instructions minimize cache pollutions by treating the memory being 
accessed as the write combining (WC) type. If a program specifies a non-temporal store with one of these instruc- 
tions and the memory type of the destination region is write back (WB), write through (WT), or write combining 
(WC), the processor will do the following: 


* If the memory location being written to is present in the cache hierarchy, the data in the caches is evicted. 


1. Some older CPU implementations (e.g., Pentium M) allowed addresses being written with a non-temporal store instruction to be 
updated in-place if the memory type was not WC and line was already in the cache. 
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¢ The non-temporal data is written to memory with WC semantics. 


See also: Chapter 11, “Memory Cache Control,” in the Inte/® 64 and IA-32 Architectures Software Developer’s 
Manual, Volume 3A. 


Using the WC semantics, the store transaction will be weakly ordered, meaning that the data may not be written to 
memory in program order, and the store will not write allocate (that is, the processor will not fetch the corre- 
sponding cache line into the cache hierarchy, prior to performing the store). Also, different processor implementa- 
tions may choose to collapse and combine these stores. 


The memory type of the region being written to can override the non-temporal hint, if the memory address speci- 
fied for the non-temporal store is in uncacheable memory. Uncacheable as referred to here means that the region 
being written to has been mapped with either an uncacheable (UC) or write protected (WP) memory type. 


In general, WC semantics require software to ensure coherence, with respect to other processors and other system 
agents (such as graphics cards). Appropriate use of synchronization and fencing must be performed for producer- 
consumer usage models. Fencing ensures that all system agents have global visibility of the stored data; for 
instance, failure to fence may result in a written cache line staying within a processor and not being visible to other 
agents. 


The memory type visible on the bus in the presence of memory type aliasing is implementation specific. As one 
possible example, the memory type written to the bus may reflect the memory type for the first store to this line, 
as seen in program order; other alternatives are possible. This behavior should be considered reserved, and 
dependence on the behavior of any particular implementation risks future incompatibility. 


NOTE 


Some older CPU implementations (e.g., Pentium M) may implement non-temporal stores by 
updating in place data that already reside in the cache hierarchy. For such processors, the 
destination region should also be mapped as WC. If mapped as WB or WT, there is the potential for 
speculative processor reads to bring the data into the caches; in this case, non-temporal stores 
would then update in place, and data would not be flushed from the processor by a subsequent 
fencing operation. 


10.4.6.3. PREFETCHhH Instructions 


The PREFETCHA instructions permit programs to load data into the processor at a suggested cache level, so that 
the data is closer to the processor’s load and store unit when it is needed. These instructions fetch 32 aligned bytes 
(or more, depending on the implementation) containing the addressed byte to a location in the cache hierarchy 
specified by the temporal locality hint (see Table 10-1). In this table, the first-level cache is closest to the processor 
and second-level cache is farther away from the processor than the first-level cache. The hints specify a prefetch 
of either temporal or non-temporal data (see Section 10.4.6.2, “Caching of Temporal vs. Non-Temporal Data”). 
Subsequent accesses to temporal data are treated like normal accesses, while those to non-temporal data will 
continue to minimize cache pollution. If the data is already present at a level of the cache hierarchy that is closer 
to the processor, the PREFETCHA instruction will not result in any data movement. The PREFETCHA instructions do 
not affect functional behavior of the program. 


See Section 11.6.13, “Cacheability Hint Instructions,” for additional information about the PREFETCHA instructions. 


Table 10-1. PREFETCHh Instructions Caching Hints 


PREFETCHh Instruction 
Mnemonic Actions 


PREFETCHTO Temporal data—fetch data into all levels of cache hierarchy: 
« Pentium Ill processor—1st-level cache or 2nd-level cache 
« Pentium 4 and Intel Xeon processor—2nd-level cache 
PREFETCHT 1 Temporal data—fetch data into level 2 cache and higher 

« Pentium Ill processor—2nd-level cache 

« Pentium 4 and Intel Xeon processor—2nd-level cache 
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Table 10-1. PREFETCHh Instructions Caching Hints (Contd.) 


PREFETCHhH Instruction 
Mnemonic Actions 


PREFETCHT2 Temporal data—fetch data into level 2 cache and higher 
« Pentium Ill processor—2nd-level cache 


« Pentium 4 and Intel Xeon processor—2nd-level cache 


PREFETCHNTA Non-temporal data—fetch data into location close to the processor, minimizing cache pollution 
« Pentium Ill processor—1st-level cache 


« Pentium 4 and Intel Xeon processor—2nd-level cache 


10.4.6.4 SFENCE Instruction 


The SFENCE (Store Fence) instruction controls write ordering by creating a fence for memory store operations. This 
instruction guarantees that the result of every store instruction that precedes the store fence in program order is 
globally visible before any store instruction that follows the fence. The SFENCE instruction provides an efficient way 
of ensuring ordering between procedures that produce weakly-ordered data and procedures that consume that 
data. 


10.5  FXSAVE AND FXRSTOR INSTRUCTIONS 


The FXSAVE and FXRSTOR instructions were introduced into the IA-32 architecture in the Pentium II processor 

family (prior to the introduction of the SSE extensions). The original versions of these instructions performed a fast 
save and restore, respectively, of the x87 execution environment (x87 state). (By saving the state of the x87 FPU 
data registers, the FXSAVE and FXRSTOR instructions implicitly save and restore the state of the MMX registers.) 


The SSE extensions expanded the scope of these instructions to save and restore the states of the XMM registers 
and the MXCSR register (SSE state), along with x87 state. 


The FXSAVE and FXRSTOR instructions can be used in place of the FSAVE/FNSAVE and FRSTOR instructions; 
however, the operation of the FXSAVE and FXRSTOR instructions are not identical to the operation of 
FSAVE/FNSAVE and FRSTOR. 


NOTE 


The FXSAVE and FXRSTOR instructions are not considered part of the SSE instruction group. They 
have a separate CPUID feature bit to indicate whether they are present (if 
CPUID.01H:EDX.FXSR[bit 24] = 1). 


The CPUID feature bit for SSE extensions does not indicate the presence of FKSAVE and FXRSTOR. 


The FXSAVE and FXRSTOR instructions organize x87 state and SSE state in a region of memory called the FXSAVE 
area. Section 10.5.1 provides details of the FXSAVE area and its format. Section 10.5.2 describes operation of 
FXSAVE, and Section 10.5.3 describes the operation of FXRSTOR. 


10.5.1 FXSAVE Area 


The FXSAVE and FXRSTOR instructions organize x87 state and SSE state in a region of memory called the FKSAVE 
area. Each of the instructions takes a memory operand that specifies the 16-byte aligned base address of the 
FXSAVE area on which it operates. 
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Every FXSAVE area comprises the 512 bytes starting at the area’s base address. Table 10-2 illustrates the format 
of the first 416 bytes of the legacy region of an FXSAVE area. 


Table 10-2. Format of an FXSAVE Area 


CS or FPU F . 
Reserved IP bits 63:32 FPU IP bits 31:0 


DS or 
MXCSR_MASK MXCSR Reserved FPU DP FPU DP bits 31:0 
bits 63:32 


Reserved ST0/MMO 
Reserved ST1/MM1 
Reserved ST2/MM2 
Reserved ST3/MM3 
Reserved ST4/MM4 
Reserved ST5/MM5 
Reserved ST6/MM6 
Reserved ST7/MM7 


The x87 state component comprises bytes 23:0 and bytes 159:32. The SSE state component comprises 
bytes 31:24 and bytes 415:160. FXSAVE and FXRSTOR do not use bytes 511:416; bytes 463:416 are reserved. 


Section 10.5.2 and Section 10.5.3 provide details of how FXSAVE and FXRSTOR use an FXSAVE area. 


10.5.1.1 x87 State 


Table 10-2 illustrates how FXSAVE and FXRSTOR organize x87 state and SSE state; the x87 state is listed below, 
along with details of its interactions with FXSAVE and FXRSTOR: 


¢ Bytes 1:0, 3:2, and 7:6 are used for x87 FPU Control Word (FCW), x87 FPU Status Word (FSW), and x87 FPU 
Opcode (FOP), respectively. 
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Byte 4 is used for an abridged version of the x87 FPU Tag Word (FTW). The following items describe its usage: 


— For each j, 0 <j <7, FXSAVE saves a 0 into bit j of byte 4 if x87 FPU data register STj has a empty tag; 
otherwise, FXSAVE saves a 1 into bit j of byte 4. 


— For each j, 0 <j < 7, FXRSTOR establishes the tag value for x87 FPU data register STj as follows. If bit j of 
byte 4 is 0, the tag for STj in the tag register for that data register is marked empty (11B); otherwise, the 
x87 FPU sets the tag for STj based on the value being loaded into that register (see below). 


Bytes 15:8 are used as follows: 
— If the instruction has no REX prefix, or if REX.W = 0: 
¢ Bytes 11:8 are used for bits 31:0 of the x87 FPU Instruction Pointer Offset (FIP). 


¢ If CPUID.(EAX=07H,ECX=0H):EBX[bit 13] = 0, bytes 13:12 are used for x87 FPU Instruction Pointer 
Selector (FPU CS). Otherwise, the processor deprecates the FPU CS value: FXSAVE saves it as OOOOH. 


¢ Bytes 15:14 are not used. 
— If the instruction has a REX prefix with REX.W = 1, bytes 15:8 are used for the full 64 bits of FIP. 
Bytes 23:16 are used as follows: 
— If the instruction has no REX prefix, or if REX.W = 0: 

¢ Bytes 19:16 are used for bits 31:0 of the x87 FPU Data Pointer Offset (FDP). 


¢ If CPUID.(EAX=07H,ECX=0H):EBX[bit 13] = 0, bytes 21:20 are used for x87 FPU Data Pointer Selector 
(FPU DS). Otherwise, the processor deprecates the FPU DS value: FXSAVE saves it as OOOOH. 


¢ Bytes 23:22 are not used. 
— If the instruction has a REX prefix with REX.W = 1, bytes 23:16 are used for the full 64 bits of FDP. 
Bytes 31:24 are used for SSE state (see Section 10.5.1.2). 


Bytes 159:32 are used for the registers STO-ST7 (MMO-MM7). Each of the 8 registers is allocated a 128-bit 
region, with the low 80 bits used for the register and the upper 48 bits unused. 


10.5.1.2 SSE State 


Table 10-2 illustrates how FXSAVE and FXRSTOR organize x87 state and SSE state; the SSE state is listed below, 
along with details of its interactions with FXSAVE and FXRSTOR: 


Bytes 23:0 are used for x87 state (see Section 10.5.1.1). 


Bytes 27:24 are used for the MXCSR register. FXRSTOR generates a general-protection fault (#GP) in response 
to an attempt to set any of the reserved bits in the MXCSR register. 


Bytes 31:28 are used for the MKCSR_MASK value. FXRSTOR ignores this field. 
Bytes 159:32 are used for x87 state. 
Bytes 287:160 are used for the registers XMMO-XMM7. 


Bytes 415:288 are used for the registers XMM8-XMM15. These fields are used only in 64-bit mode. Executions 
of FXSAVE outside 64-bit mode do not write to these bytes; executions of FXRSTOR outside 64-bit mode do not 
read these bytes and do not update XMM8-XMM15. 


If CR4.OSFXSR = 0, FXSAVE and FXRSTOR may or may not operate on SSE state; this behavior is implementation 
dependent. Moreover, SSE instructions cannot be used unless CR4.OSFXSR = 1. 


10.5.2 Operation of FXSAVE 


The FXSAVE instruction takes a single memory operand, which is an FXSAVE area. The instruction stores x87 state 
and SSE state to the FXSAVE area. See Section 10.5.1.1 and Section 10.5.1.2 for details regarding mode-specific 
operation and operation determined by instruction prefixes. 
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10.5.3. Operation of FXRSTOR 


The FXRSTOR instruction takes a single memory operand, which is an FXSAVE area. If the value at bytes 27:24 of 
the FXSAVE area is not a legal value for the MXCSR register (e.g., the value sets reserved bits), execution of 
FXRSTOR results in a general-protection fault (#GP). Otherwise, the instruction loads x87 state and SSE state rom 
the FXSAVE area. See Section 10.5.1.1 and Section 10.5.1.2 for details regarding mode-specific operation and 
operation determined by instruction prefixes. 


10.6 HANDLING SSE INSTRUCTION EXCEPTIONS 


See Section 11.5, “SSE, SSE2, and SSE3 Exceptions,” for a detailed discussion of the general and SIMD floating- 
point exceptions that can be generated with the SSE instructions and for guidelines for handling these exceptions 
when they occur. 


10.7. ~WRITING APPLICATIONS WITH THE SSE EXTENSIONS 


See Section 11.6, “Writing Applications with SSE/SSE2 Extensions,” for additional information about writing appli- 
cations and operating-system code using the SSE extensions. 
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CHAPTER 11 
PROGRAMMING WITH INTEL® 
STREAMING SIMD EXTENSIONS 2 (INTEL® SSE2) 


The streaming SIMD extensions 2 (SSE2) were introduced into the IA-32 architecture in the Pentium 4 and Intel 
Xeon processors. These extensions enhance the performance of IA-32 processors for advanced 3-D graphics, video 
decoding/encoding, speech recognition, E-commerce, Internet, scientific, and engineering applications. 


This chapter describes the SSE2 extensions and provides information to assist in writing application programs that 
use these and the SSE extensions. 


11.1 OVERVIEW OF SSE2 EXTENSIONS 


SSE2 extensions use the single instruction multiple data (SIMD) execution model that is used with MMX technology 
and SSE extensions. They extend this model with support for packed double-precision floating-point values and for 
128-bit packed integers. 


If CPUID.OLH:EDX.SSE2[bit 26] = 1, SSE2 extensions are present. 

SSE2 extensions add the following features to the IA-32 architecture, while maintaining backward compatibility 
with all existing IA-32 processors, applications and operating systems. 

° Six data types: 


— 128-bit packed double-precision floating-point (two IEEE Standard 754 double-precision floating-point 
values packed into a double quadword) 


— 128-bit packed byte integers 
— 128-bit packed word integers 
— 128-bit packed doubleword integers 
— 128-bit packed quadword integers 
¢ Instructions to support the additional data types and extend existing SIMD integer operations: 
— Packed and scalar double-precision floating-point instructions 
— Additional 64-bit and 128-bit SIMD integer instructions 
— 128-bit versions of SIMD integer instructions introduced with the MMX technology and the SSE extensions 
— Additional cacheability-control and instruction-ordering instructions 
° Modifications to existing IA-32 instructions to support SSE2 features: 
— Extensions and modifications to the CPUID instruction 
— Modifications to the RDPMC instruction 


These new features extend the IA-32 architecture’s SIMD programming model in three important ways: 


° They provide the ability to perform SIMD operations on pairs of packed double-precision floating-point values. 
This permits higher precision computations to be carried out in XMM registers, which enhances processor 
performance in scientific and engineering applications and in applications that use advanced 3-D geometry 
techniques (such as ray tracing). Additional flexibility is provided with instructions that operate on single 
(scalar) double-precision floating-point values located in the low quadword of an XMM register. 


° They provide the ability to operate on 128-bit packed integers (bytes, words, doublewords, and quadwords) in 
XMM registers. This provides greater flexibility and greater throughput when performing SIMD operations on 
packed integers. The capability is particularly useful for applications such as RSA authentication and RC5 
encryption. Using the full set of SIMD registers, data types, and instructions provided with the MMX technology 
and SSE/SSE2 extensions, programmers can develop algorithms that finely mix packed single- and double- 
precision floating-point data and 64- and 128-bit packed integer data. 


¢ SSE2 extensions enhance the support introduced with SSE extensions for controlling the cacheability of SIMD 
data. SSE2 cache control instructions provide the ability to stream data in and out of the XMM registers without 
polluting the caches and the ability to prefetch data before it is actually used. 
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SSE2 extensions are fully compatible with all software written for IA-32 processors. All existing software continues 
to run correctly, without modification, on processors that incorporate SSE2 extensions, as well as in the presence 
of applications that incorporate these extensions. Enhancements to the CPUID instruction permit detection of the 
SSE2 extensions. Also, because the SSE2 extensions use the same registers as the SSE extensions, no new oper- 
ating-system support is required for saving and restoring program state during a context switch beyond that 
provided for the SSE extensions. 


SSE2 extensions are accessible from all IA-32 execution modes: protected mode, real address mode, virtual 8086 
mode. 


The following sections in this chapter describe the programming environment for SSE2 extensions including: the 
128-bit XMM floating-point register set, data types, and SSE2 instructions. It also describes exceptions that can be 
generated with the SSE and SSE2 instructions and gives guidelines for writing applications with SSE and SSE2 
extensions. 


For additional information about SSE2 extensions, see: 


° Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A & 2B, provide a detailed 
description of individual SSE3 instructions. 


° Chapter 13, “System Programming for Instruction Set Extensions and Processor Extended States,” in the 
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, gives guidelines for integrating 
the SSE and SSE2 extensions into an operating-system environment. 


11.2 SSE2 PROGRAMMING ENVIRONMENT 


Figure 11-1 shows the programming environment for SSE2 extensions. No new registers or other instruction 
execution state are defined with SSE2 extensions. SSE2 instructions use the XMM registers, the MMX registers, 
and/or IA-32 general-purpose registers, as follows: 


° XMM registers — These eight registers (See Figure 10-2) are used to operate on packed or scalar double- 
precision floating-point data. Scalar operations are operations performed on individual (unpacked) double- 
precision floating-point values stored in the low quadword of an XMM register. XMM registers are also used to 
perform operations on 128-bit packed integer data. They are referenced by the names XMMO through XMM7. 


Address Space 
32_ 7 
XMM Registers ane 
Eight 128-Bit 
MXCSR Register 32 Bits 
MMX Registers 
Eight 64-Bit 
General-Purpose 
Registers 
Eight 32-Bit 
0 
EFLAGS Register 32 Bits 


Figure 11-1. Steaming SIMD Extensions 2 Execution Environment 


° MXCSR register — This 32-bit register (see Figure 10-3) provides status and control bits used in floating-point 
operations. The denormals-are-zeros and flush-to-zero flags in this register provide a higher performance 
alternative for the handling of denormal source operands and denormal (underflow) results. For more 
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information on the functions of these flags see Section 10.2.3.4, ‘Denormals-Are-Zeros,” and Section 10.2.3.3, 
“Flush-To-Zero.” 


° MMxX registers — These eight registers (see Figure 9-2) are used to perform operations on 64-bit packed 
integer data. They are also used to hold operands for some operations performed between MMX and XMM 
registers. MMX registers are referenced by the names MMO through MM7. 


° General-purpose registers — The eight general-purpose registers (see Figure 3-5) are used along with the 
existing IA-32 addressing modes to address operands in memory. MMX and XMM registers cannot be used to 
address memory. The general-purpose registers are also used to hold operands for some SSE2 instructions. 
These registers are referenced by the names EAX, EBX, ECX, EDX, EBP, ESI, EDI, and ESP. 


° EFLAGS register — This 32-bit register (see Figure 3-8) is used to record the results of some compare 
operations. 


11.2.1. SSE2 in 64-Bit Mode and Compatibility Mode 

In compatibility mode, SSE2 extensions function like they do in protected mode. In 64-bit mode, eight additional 
XMM registers are accessible. Registers XMM8-XMM15 are accessed by using REX prefixes. 

Memory operands are specified using the ModR/M, SIB encoding described in Section 3.7.5. 


Some SSE2 instructions may be used to operate on general-purpose registers. Use the REX.W prefix to access 64- 
bit general-purpose registers. Note that if a REX prefix is used when it has no meaning, the prefix is ignored. 


11.2.2 Compatibility of SSE2 Extensions with SSE, MMX 
Technology and x87 FPU Programming Environment 


SSE2 extensions do not introduce any new state to the IA-32 execution environment beyond that of SSE. SSE2 
extensions represent an enhancement of SSE extensions; they are fully compatible and share the same state infor- 
mation. SSE and SSE2 instructions can be executed together in the same instruction stream without the need to 
save state when switching between instruction sets. 


XMM registers are independent of the x87 FPU and MMX registers; so SSE and SSE2 operations performed on XMM 
registers can be performed in parallel with x87 FPU or MMX technology operations (see Section 11.6.7, “Interaction 
of SSE/SSE2 Instructions with x87 FPU and MMX Instructions”). 


The FXSAVE and FXRSTOR instructions save and restore the SSE and SSE2 states along with the x87 FPU and MMX 
states. 


11.2.3. Denormals-Are-Zeros Flag 


The denormals-are-zeros flag (bit 6 in the MXCSR register) was introduced into the IA-32 architecture with the 
SSE2 extensions. See Section 10.2.3.4, ‘Denormals-Are-Zeros,” for a description of this flag. 


11.3. SS€2 DATA TYPES 


SSE2 extensions introduced one 128-bit packed floating-point data type and four 128-bit SIMD integer data types 
to the IA-32 architecture (see Figure 11-2). 


¢ Packed double-precision floating-point — This 128-bit data type consists of two IEEE 64-bit double- 
precision floating-point values packed into a double quadword. (See Figure 4-3 for the layout of a 64-bit 
double-precision floating-point value; refer to Section 4.2.2, “Floating-Point Data Types,” for a detailed 
description of double-precision floating-point values. ) 


* 128-bit packed integers — The four 128-bit packed integer data types can contain 16 byte integers, 8 word 
integers, 4 doubleword integers, or 2 quadword integers. (Refer to Section 4.6.2, “128-Bit Packed SIMD Data 
Types,” for a detailed description of the 128-bit packed integers.) 
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Figure 11-2. Data Types Introduced with the SSE2 Extensions 


All of these data types are operated on in XMM registers or memory. Instructions are provided to convert between 
these 128-bit data types and the 64-bit and 32-bit data types. 


The address of a 128-bit packed memory operand must be aligned on a 16-byte boundary, except in the following 
cases: 


¢ a MOVUPD instruction which supports unaligned accesses 
° scalar instructions that use an 8-byte memory operand that is not subject to alignment requirements 
Figure 4-2 shows the byte order of 128-bit (double quadword) and 64-bit (quadword) data types in memory. 


11.4 SSE2 INSTRUCTIONS 


The SSE2 instructions are divided into four functional groups: 

* Packed and scalar double-precision floating-point instructions 

°® 64-bit and 128-bit SIMD integer instructions 

° 128-bit extensions of SIMD integer instructions introduced with the MMX technology and the SSE extensions 
* Cacheability-control and instruction-ordering instructions 

The following sections provide more information about each group. 


11.4.1. Packed and Scalar Double-Precision Floating-Point Instructions 

The packed and scalar double-precision floating-point instructions are divided into the following sub-groups: 
¢ Data movement instructions 

e ~=Arithmetic instructions 

* Comparison instructions 

* Conversion instructions 

¢ Logical instructions 

¢ Shuffle instructions 


The packed double-precision floating-point instructions perform SIMD operations similarly to the packed single- 
precision floating-point instructions (see Figure 11-3). Each source operand contains two double-precision floating - 
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point values, and the destination operand contains the results of the operation (OP) performed in parallel on the 
corresponding values (XO and YO, and X1 and Y1) in each operand. 


x1 X0 
Y1 YO 
X1 OP Y1 X0 OP YO 


Figure 11-3. Packed Double-Precision Floating-Point Operations 


The scalar double-precision floating-point instructions operate on the low (least significant) quadwords of two 
source operands (XO and YO), as shown in Figure 11-4. The high quadword (X1) of the first source operand is 
passed through to the destination. The scalar operations are similar to the floating-point operations performed in 
x87 FPU data registers with the precision control field in the x87 FPU control word set for double precision (53-bit 
significand), except that x87 stack operations use a 15-bit exponent range for the result while SSE2 operations use 
an 11-bit exponent range. 

See Section 11.6.8, “Compatibility of SIMD and x87 FPU Floating-Point Data Types,” for more information about 
obtaining compatible results when performing both scalar double-precision floating-point operations in XMM regis- 
ters and in x87 FPU data registers. 


x1 X0 OP YO 


Figure 11-4. Scalar Double-Precision Floating-Point Operations 


11.4.1.1 Data Movement Instructions 


Data movement instructions move double-precision floating-point data between XMM registers and between XMM 
registers and memory. 


The MOVAPD (move aligned packed double-precision floating-point) instruction transfers a 128-bit packed double- 
precision floating-point operand from memory to an XMM register or vice versa, or between XMM registers. The 
memory address must be aligned to a 16-byte boundary; if not, a general-protection exception (GP#) is gener- 
ated. 
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The MOVUPD (move unaligned packed double-precision floating-point) instruction transfers a 128-bit packed 
double-precision floating-point operand from memory to an XMM register or vice versa, or between XMM registers. 
Alignment of the memory address is not required. 


The MOVSD (move scalar double-precision floating-point) instruction transfers a 64-bit double-precision floating- 
point operand from memory to the low quadword of an XMM register or vice versa, or between XMM registers. 
Alignment of the memory address is not required, unless alignment checking is enabled. 


The MOVHPD (move high packed double-precision floating-point) instruction transfers a 64-bit double-precision 
floating-point operand from memory to the high quadword of an XMM register or vice versa. The low quadword of 
the register is left unchanged. Alignment of the memory address is not required, unless alignment checking is 
enabled. 


The MOVLPD (move low packed double-precision floating-point) instruction transfers a 64-bit double-precision 
floating-point operand from memory to the low quadword of an XMM register or vice versa. The high quadword of 
the register is left unchanged. Alignment of the memory address is not required, unless alignment checking is 
enabled. 


The MOVMSKPD (move packed double-precision floating-point mask) instruction extracts the sign bit of each of the 
two packed double-precision floating-point numbers in an XMM register and saves them in a general-purpose 
register. This 2-bit value can then be used as a condition to perform branching. 


11.4.1.2 SSE2 Arithmetic Instructions 


SSE2 arithmetic instructions perform addition, subtraction, multiply, divide, square root, and maximum/minimum 
operations on packed and scalar double-precision floating-point values. 


The ADDPD (add packed double-precision floating-point values) and SUBPD (subtract packed double-precision 
floating-point values) instructions add and subtract, respectively, two packed double-precision floating-point oper- 
ands. 


The ADDSD (add scalar double-precision floating-point values) and SUBSD (subtract scalar double-precision 
floating-point values) instructions add and subtract, respectively, the low double-precision floating-point values of 
two operands and stores the result in the low quadword of the destination operand. 


The MULPD (multiply packed double-precision floating-point values) instruction multiplies two packed double- 
precision floating-point operands. 


The MULSD (multiply scalar double-precision floating-point values) instruction multiplies the low double-precision 
floating-point values of two operands and stores the result in the low quadword of the destination operand. 


The DIVPD (divide packed double-precision floating-point values) instruction divides two packed double-precision 
floating-point operands. 


The DIVSD (divide scalar double-precision floating-point values) instruction divides the low double-precision 
floating-point values of two operands and stores the result in the low quadword of the destination operand. 


The SQRTPD (compute square roots of packed double-precision floating-point values) instruction computes the 
square roots of the values in a packed double-precision floating-point operand. 


The SQRTSD (compute square root of scalar double-precision floating-point values) instruction computes the 
square root of the low double-precision floating-point value in the source operand and stores the result in the low 
quadword of the destination operand. 


The MAXPD (return maximum of packed double-precision floating-point values) instruction compares the corre- 
sponding values in two packed double-precision floating-point operands and returns the numerically greater value 
from each comparison to the destination operand. 


The MAXSD (return maximum of scalar double-precision floating-point values) instruction compares the low 
double-precision floating-point values from two packed double-precision floating-point operands and returns the 
numerically higher value from the comparison to the low quadword of the destination operand. 


The MINPD (return minimum of packed double-precision floating-point values) instruction compares the corre- 
sponding values from two packed double-precision floating-point operands and returns the numerically lesser value 
from each comparison to the destination operand. 
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The MINSD (return minimum of scalar double-precision floating-point values) instruction compares the low values 
from two packed double-precision floating-point operands and returns the numerically lesser value from the 
comparison to the low quadword of the destination operand. 


11.4.1.3. SSE2 Logical Instructions 


SSE2 logical instructions perform AND, AND NOT, OR, and XOR operations on packed double-precision floating- 
point values. 


The ANDPD (bitwise logical AND of packed double-precision floating-point values) instruction returns the logical 
AND of two packed double-precision floating-point operands. 


The ANDNPD (bitwise logical AND NOT of packed double-precision floating-point values) instruction returns the 
logical AND NOT of two packed double-precision floating-point operands. 


The ORPD (bitwise logical OR of packed double-precision floating-point values) instruction returns the logical OR of 
two packed double-precision floating-point operands. 


The XORPD (bitwise logical XOR of packed double-precision floating-point values) instruction returns the logical 
XOR of two packed double-precision floating-point operands. 


11.4.1.4 SSE2 Comparison Instructions 


SSE2 compare instructions compare packed and scalar double-precision floating-point values and return the 
results of the comparison either to the destination operand or to the EFLAGS register. 


The CMPPD (compare packed double-precision floating-point values) instruction compares the corresponding 
values from two packed double-precision floating-point operands, using an immediate operand as a predicate, and 
returns a 64-bit mask result of all 1s or all Os for each comparison to the destination operand. The value of the 
immediate operand allows the selection of any of eight compare conditions: equal, less than, less than equal, unor- 
dered, not equal, not less than, not less than or equal, or ordered. 


The CMPSD (compare scalar double-precision floating-point values) instruction compares the low values from two 
packed double-precision floating-point operands, using an immediate operand as a predicate, and returns a 64-bit 
mask result of all 1s or all Os for the comparison to the low quadword of the destination operand. The immediate 
operand selects the compare condition as with the CMPPD instruction. 


The COMISD (compare scalar double-precision floating-point values and set EFLAGS) and UCOMISD (unordered 
compare scalar double-precision floating-point values and set EFLAGS) instructions compare the low values of two 
packed double-precision floating-point operands and set the ZF, PF, and CF flags in the EFLAGS register to show the 
result (greater than, less than, equal, or unordered). These two instructions differ as follows: the COMISD instruc- 
tion signals a floating-point invalid-operation (#1) exception when a source operand is either a QNaN or an SNaN; 
the UCOMISD instruction only signals an invalid-operation exception when a source operand is an SNaN. 


11.4.1.5 SSE2 Shuffle and Unpack Instructions 


SSE2 shuffle instructions shuffle the contents of two packed double-precision floating-point values and store the 
results in the destination operand. 


The SHUFPD (shuffle packed double-precision floating-point values) instruction places either of the two packed 
double-precision floating-point values from the destination operand in the low quadword of the destination 
operand, and places either of the two packed double-precision floating-point values from source operand in the 
high quadword of the destination operand (see Figure 11-5). By using the same register for the source and desti- 
nation operands, the SHUFPD instruction can swap two packed double-precision floating-point values. 
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DEST x1 X0 
SRC Y1 YO 
DEST Y1 or YO X11 or XO 


Figure 11-5. SHUFPD Instruction, Packed Shuffle Operation 


The UNPCKHPD (unpack and interleave high packed double-precision floating-point values) instruction performs an 


interleaved unpack of the high values from the source and destination operands and stores the result in the desti- 
nation operand (see Figure 11-6). 


The UNPCKLPD (unpack and interleave low packed double-precision floating-point values) instruction performs an 


interleaved unpack of the low values from the source and destination operands and stores the result in the desti- 
nation operand (see Figure 11-7). 


DEST x1 x0 
SRC Y1 YO 
DEST v1 x1 


Figure 11-6. UNPCKHPD Instruction, High Unpack and Interleave Operation 


DEST x1 X0 
SRC Y1 YO 
DEST YO xo 


Figure 11-7. UNPCKLPD Instruction, Low Unpack and Interleave Operation 
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11.4.1.6 SSE2 Conversion Instructions 


SSE2 conversion instructions (see Figure 11-8) support packed and scalar conversions between: 
* Double-precision and single-precision floating-point formats 

* Double-precision floating-point and doubleword integer formats 

°® Single-precision floating-point and doubleword integer formats 


Conversion between double-precision and single-precision floating-points values — The following 
instructions convert operands between double-precision and single-precision floating-point formats. The operands 
being operated on are contained in XMM registers or memory (at most, one operand can reside in memory; the 
destination is always an MMX register). 


The CVTPS2PD (convert packed single-precision floating-point values to packed double-precision floating-point 
values) instruction converts two packed single- 
precision floating-point values to two double-precision floating-point values. 


The CVTPD2PS (convert packed double-precision floating-point values to packed single-precision floating-point 
values) instruction converts two packed double- 

precision floating-point values to two single-precision floating-point values. When a conversion is inexact, the 
result is rounded according to the rounding mode selected in the MXCSR register. 


The CVTSS2SD (convert scalar single-precision floating-point value to scalar double-precision floating-point value) 
instruction converts a single-precision floating-point value to a double-precision floating-point value. 


The CVTSD2SS (convert scalar double-precision floating-point value to scalar single-precision floating-point value) 
instruction converts a double-precision floating-point value to a single-precision floating-point value. When the 
conversion is inexact, the result is rounded according to the rounding mode selected in the MXCSR register. 


Single-Precisio 
Floating Point 
(XMM/mem) 


4 Doubleword 
Integer 
(XMM/mem) 


Doubleword 


CVTSD2SS 
CVTPD2PS 
AdZSd LAD 
aSzSSLAO 


Integer Integer 2 Doubleword 
(MMX/mem) Integer 
(XMM/mem) 


Double-Precision 
Floating-Point 
(XMM/mem) 


Figure 11-8. SSE and SSE2 Conversion Instructions 


Conversion between double-precision floating-point values and doubleword integers — The following 
instructions convert operands between double-precision floating-point and doubleword integer formats. Operands 
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are housed in XMM registers, MMX registers, general registers or memory (at most one operand can reside in 
memory; the destination is always an XMM, MMX, or general register). 


The CVTPD2PI (convert packed double-precision floating-point values to packed doubleword integers) instruction 
converts two packed double-precision floating-point numbers to two packed signed doubleword integers, with the 
result stored in an MMX register. When rounding to an integer value, the source value is rounded according to the 
rounding mode in the MXCSR register. The CVTTPD2PI (convert with truncation packed double-precision floating- 
point values to packed doubleword integers) instruction is similar to the CVTPD2PI instruction except that trunca- 
tion is used to round a source value to an integer value (see Section 4.8.4.2, “Truncation with SSE and SSE2 
Conversion Instructions”). 


The CVTPI2PD (convert packed doubleword integers to packed double-precision floating-point values) instruction 
converts two packed signed doubleword integers to two double-precision floating-point values. 


The CVTPD2DQ (convert packed double-precision floating-point values to packed doubleword integers) instruction 
converts two packed double-precision floating-point numbers to two packed signed doubleword integers, with the 
result stored in the low quadword of an XMM register. When rounding an integer value, the source value is rounded 
according to the rounding mode selected in the MXCSR register. The CVTTPD2DQ (convert with truncation packed 
double-precision floating-point values to packed doubleword integers) instruction is similar to the CVTPD2DQ 
instruction except that truncation is used to round a source value to an integer value (see Section 4.8.4.2, “Trun- 
cation with SSE and SSE2 Conversion Instructions”). 


The CVTDQ2PD (convert packed doubleword integers to packed double-precision floating-point values) instruction 
converts two packed signed doubleword integers located in the low-order doublewords of an XMM register to two 
double-precision floating-point values. 


The CVTSD2SI (convert scalar double-precision floating-point value to doubleword integer) instruction converts a 
double-precision floating-point value to a doubleword integer, and stores the result in a general-purpose register. 
When rounding an integer value, the source value is rounded according to the rounding mode selected in the 
MXCSR register. The CVTTSD2SI (convert with truncation scalar double-precision floating-point value to double- 
word integer) instruction is similar to the CVTSD2SI instruction except that truncation is used to round the source 
value to an integer value (see Section 4.8.4.2, “Truncation with SSE and SSE2 Conversion Instructions”). 


The CVTSI2SD (convert doubleword integer to scalar double-precision floating-point value) instruction converts a 
signed doubleword integer in a general-purpose register to a double-precision floating-point number, and stores 
the result in an XMM register. 


Conversion between single-precision floating-point and doubleword integer formats — These instruc- 
tions convert between packed single-precision floating-point and packed doubleword integer formats. Operands 
are housed in XMM registers, MMX registers, general registers, or memory (the latter for at most one source 
operand). The destination is always an XMM, MMX, or general register. These SSE2 instructions supplement 
conversion instructions (CVTPI2PS, CVTPS2PI, CVTTPS2PI, CVTSI2SS, CVTSS2SI, and CVTTSS2SI) introduced 
with SSE extensions. 


The CVTPS2DQ (convert packed single-precision floating-point values to packed doubleword integers) instruction 
converts four packed single-precision floating-point values to four packed signed doubleword integers, with the 
source and destination operands in XMM registers or memory (the latter for at most one source operand). When 
the conversion is inexact, the rounded value according to the rounding mode selected in the MXCSR register is 
returned. The CVTTPS2DQ (convert with truncation packed single-precision floating-point values to packed double- 
word integers) instruction is similar to the CVTPS2DQ instruction except that truncation is used to round a source 
value to an integer value (see Section 4.8.4.2, “Truncation with SSE and SSE2 Conversion Instructions”). 


The CVTDQ2PS (convert packed doubleword integers to packed single-precision floating-point values) instruction 
converts four packed signed doubleword integers to four packed single-precision floating-point numbers, with the 
source and destination operands in XMM registers or memory (the latter for at most one source operand). When 
the conversion is inexact, the rounded value according to the rounding mode selected in the MXCSR register is 
returned. 


11.4.2 SSE2 64-Bit and 128-Bit SIMD Integer Instructions 


SSE2 extensions add several 128-bit packed integer instructions to the IA-32 architecture. Where appropriate, a 
64-bit version of each of these instructions is also provided. The 128-bit versions of instructions operate on data in 
XMM registers; 64-bit versions operate on data in MMX registers. The instructions follow. 
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The MOVDQA (move aligned double quadword) instruction transfers a double quadword operand from memory to 
an XMM register or vice versa; or between XMM registers. The memory address must be aligned to a 16-byte 
boundary; otherwise, a general-protection exception (#GP) is generated. 


The MOVDQU (move unaligned double quadword) instruction performs the same operations as the MOVDQA 
instruction, except that 16-byte alignment of a memory address is not required. 


The PADDQ (packed quadword add) instruction adds two packed quadword integer operands or two single quad- 
word integer operands, and stores the results in an XMM or MMX register, respectively. This instruction can operate 
on either unsigned or signed (two’s complement notation) integer operands. 


The PSUBQ (packed quadword subtract) instruction subtracts two packed quadword integer operands or two single 
quadword integer operands, and stores the results in an XMM or MMX register, respectively. Like the PADDQ 
instruction, PSUBQ can operate on either unsigned or signed (two’s complement notation) integer operands. 


The PMULUDQ (multiply packed unsigned doubleword integers) instruction performs an unsigned multiply of 
unsigned doubleword integers and returns a quadword result. Both 64-bit and 128-bit versions of this instruction 
are available. The 64-bit version operates on two doubleword integers stored in the low doubleword of each source 
operand, and the quadword result is returned to an MMX register. The 128-bit version performs a packed multiply 
of two pairs of doubleword integers. Here, the doublewords are packed in the first and third doublewords of the 
source operands, and the quadword results are stored in the low and high quadwords of an XMM register. 


The PSHUFLW (shuffle packed low words) instruction shuffles the word integers packed into the low quadword of 
the source operand and stores the shuffled result in the low quadword of the destination operand. An 8-bit imme- 
diate operand specifies the shuffle order. 


The PSHUFHW (shuffle packed high words) instruction shuffles the word integers packed into the high quadword of 
the source operand and stores the shuffled result in the high quadword of the destination operand. An 8-bit imme- 
diate operand specifies the shuffle order. 


The PSHUFD (shuffle packed doubleword integers) instruction shuffles the doubleword integers packed into the 
source operand and stores the shuffled result in the destination operand. An 8-bit immediate operand specifies the 
shuffle order. 


The PSLLDQ (shift double quadword left logical) instruction shifts the contents of the source operand to the left by 
the amount of bytes specified by an immediate operand. The empty low-order bytes are cleared (set to 0). 


The PSRLDQ (shift double quadword right logical) instruction shifts the contents of the source operand to the right 
by the amount of bytes specified by an immediate operand. The empty high-order bytes are cleared (set to 0). 


The PUNPCKHQDQ (Unpack high quadwords) instruction interleaves the high quadword of the source operand and 
the high quadword of the destination operand and writes them to the destination register. 


The PUNPCKLQDQ (Unpack low quadwords) instruction interleaves the low quadwords of the source operand and 
the low quadwords of the destination operand and writes them to the destination register. 


Two additional SSE instructions enable data movement from the MMX registers to the XMM registers. 


The MOVQ2DQ (move quadword integer from MMX to XMM registers) instruction moves the quadword integer from 
an MMX source register to an XMM destination register. 


The MOVDQ2Q (move quadword integer from XMM to MMX registers) instruction moves the low quadword integer 
from an XMM source register to an MMX destination register. 


11.4.3. 128-Bit SIMD Integer Instruction Extensions 


All of 64-bit SIMD integer instructions introduced with MMX technology and SSE extensions (with the exception of 
the PSHUFW instruction) have been extended by SSE2 extensions to operate on 128-bit packed integer operands 
located in XMM registers. The 128-bit versions of these instructions follow the same SIMD conventions regarding 
packed operands as the 64-bit versions. For example, where the 64-bit version of the PADDB instruction operates 
on 8 packed bytes, the 128-bit version operates on 16 packed bytes. 
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11.4.4 Cacheability Control and Memory Ordering Instructions 


SSE2 extensions that give programs more control over the caching, loading, and storing of data. are described 
below. 


11.4.4.1 FLUSH Cache Line 


The CLFLUSH (flush cache line) instruction writes and invalidates the cache line associated with a specified linear 
address. The invalidation is for all levels of the processor’s cache hierarchy, and it is broadcast throughout the 
cache coherency domain. 


NOTE 


CLFLUSH was introduced with the SSE2 extensions. However, the instruction can be implemented 
in IA-32 processors that do not implement the SSE2 extensions. Detect CLFLUSH using the feature 
bit (if CPUID.01H:EDX.CLFSH[bit 19] = 1). 


11.4.4.2 Cacheability Control Instructions 


The following four instructions enable data from XMM and general-purpose registers to be stored to memory using 
a non-temporal hint. The non-temporal hint directs the processor to store data to memory without writing the data 
into the cache hierarchy. See Section 10.4.6.2, “Caching of Temporal vs. Non-Temporal Data,” for more information 
about non-temporal stores and hints. 


The MOVNTDQ (store double quadword using non-temporal hint) instruction stores packed integer data from an 
XMM register to memory, using a non-temporal hint. 


The MOVNTPD (store packed double-precision floating-point values using non-temporal hint) instruction stores 
packed double-precision floating-point data from an XMM register to memory, using a non-temporal hint. 


The MOVNTI (store doubleword using non-temporal hint) instruction stores integer data from a general-purpose 
register to memory, using a non-temporal hint. 


The MASKMOVDQU (store selected bytes of double quadword) instruction stores selected byte integers from an 
XMM register to memory, using a byte mask to selectively write the individual bytes. The memory location does not 
need to be aligned on a natural boundary. This instruction also uses a non-temporal hint. 


11.4.4.3. Memory Ordering Instructions 


SSE2 extensions introduce two new fence instructions (LFENCE and MFENCE) as companions to the SFENCE 
instruction introduced with SSE extensions. 


The LFENCE instruction establishes a memory fence for loads. It guarantees ordering between two loads and 
prevents speculative loads from passing the load fence (that is, no speculative loads are allowed until all loads 
specified before the load fence have been carried out). 


The MFENCE instruction establishes a memory fence for both loads and stores. The processor ensures that no load 
or store after MFENCE will become globally visible until all loads and stores before MFENCE are globally visible.? 
Note that the sequences LFENCE;SFENCE and SFENCE;LFENCE are not equivalent to MFENCE because neither 
ensures that older stores are globally observed prior to younger loads. 


11.4.4.4 Pause 


The PAUSE instruction is provided to improve the performance of “spin-wait loops” executed on a Pentium 4 or Intel 
Xeon processor. On a Pentium 4 processor, it also provides the added benefit of reducing processor power 
consumption while executing a spin-wait loop. It is recommended that a PAUSE instruction always be included in 
the code sequence for a spin-wait loop. 


1. Aload is considered to become globally visible when the value to be loaded is determined. 
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11.4.5 Branch Hints 


SSE2 extensions designate two instruction prefixes (2EH and 3EH) to provide branch hints to the processor (see 
“Instruction Prefixes” in Chapter 2 of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 
2A). These prefixes can only be used with the Jcc instruction and only at the machine code level (that is, there are 
no mnemonics for the branch hints). 


11.5 SSE, SSE2, AND SSE3 EXCEPTIONS 


SSE/SSE2/SSE3 extensions generate two general types of exceptions: 

¢ Non-numeric exceptions 

* SIMD floating-point exceptions? 

SSE/SSE2/SSE3 instructions can generate the same type of memory-access and non-numeric exceptions as other 
IA-32 architecture instructions. Existing exception handlers can generally handle these exceptions without any 
code modification. See “Providing Non-Numeric Exception Handlers for Exceptions Generated by the SSE, SSE2 
and SSE3 Instructions” in Chapter 13 of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, 


Volume 3A, for a list of the non-numeric exceptions that can be generated by SSE/SSE2/SSE3 instructions and for 
guidelines for handling these exceptions. 


SSE/SSE2/SSE3 instructions do not generate numeric exceptions on packed integer operations; however, they can 
generate numeric (SIMD floating-point) exceptions on packed single-precision and double-precision floating-point 
operations. These SIMD floating-point exceptions are defined in the IEEE Standard 754 for Binary Floating-Point 
Arithmetic and are the same exceptions that are generated for x87 FPU instructions. See Section 11.5.1, “SIMD 
Floating-Point Exceptions,” for a description of these exceptions. 


11.5.1. SIMD Floating-Point Exceptions 


SIMD floating-point exceptions are those exceptions that can be generated by SSE/SSE2/SSE3 instructions that 
operate on packed or scalar floating-point operands. 


Six classes of SIMD floating-point exceptions can be generated: 
¢ Invalid operation (#1) 

°* Divide-by-zero (#Z) 

¢ Denormal operand (#D) 

¢ Numeric overflow (#0) 

¢ Numeric underflow (#U) 

¢  Inexact result (Precision) (#P) 


All of these exceptions (except the denormal operand exception) are defined in IEEE Standard 754, and they are 
the same exceptions that are generated with the x87 floating-point instructions. Section 4.9, “Overview of 
Floating-Point Exceptions,” gives a detailed description of these exceptions and of how and when they are gener- 
ated. The following sections discuss the implementation of these exceptions in SSE/SSE2/SSE3 extensions. 


All SIMD floating-point exceptions are precise and occur as soon as the instruction completes execution. 


Each of the six exception conditions has a corresponding flag (IE, DE, ZE, OE, UE, and PE) and mask bit (IM, DM, 
ZM, OM, UM, and PM) in the MXCSR register (see Figure 10-3). The mask bits can be set with the LDMXCSR or 
FXRSTOR instruction; the mask and flag bits can be read with the STMXCSR or FXSAVE instruction. 


The OSXMMEXCEPT flag (bit 10) of control register CR4 provides additional control over generation of SIMD 
floating-point exceptions by allowing the operating system to indicate whether or not it supports software excep- 
tion handlers for SIMD floating-point exceptions. If an unmasked SIMD floating-point exception is generated and 
the OSXMMEXCEPT flag is set, the processor invokes a software exception handler by generating a SIMD floating- 


1. The FISTTP instruction in SSE3 does not generate SIMD floating-point exceptions, but it can generate x87 FPU floating-point excep- 
tions. 
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point exception (#XM). If the OSXMMEXCEPT bit is clear, the processor generates an invalid-opcode exception 
(#UD) on the first SSE or SSE2 instruction that detects a SIMD floating-point exception condition. See Section 
11.6.2, “Checking for SSE/SSE2 Support.” 


11.5.2 SIMD Floating-Point Exception Conditions 


The following sections describe the conditions that cause a SIMD floating-point exception to be generated and the 
masked response of the processor when these conditions are detected. 


See Section 4.9.2, “Floating-Point Exception Priority,” for a description of the rules for exception precedence when 
more than one floating-point exception condition is detected for an instruction. 


11.5.2.1 Invalid Operation Exception (#1) 


The floating-point invalid-operation exception (#I) occurs in response to an invalid arithmetic operand. The flag 
(IE) and mask (IM) bits for the invalid operation exception are bits 0 and 7, respectively, in the MXCSR register. 


If the invalid-operation exception is masked, the processor returns a QNaN, QNaN floating-point indefinite, integer 
indefinite, one of the source operands to the destination operand, or it sets the EFLAGS, depending on the operation 
being performed. When a value is returned to the destination operand, it overwrites the destination register specified 
by the instruction. Table 11-1 lists the invalid-arithmetic operations that the processor detects for instructions and 
the masked responses to these operations. 


Table 11-1. Masked Responses of SSE/SSE2/SSE3 Instructions to Invalid Arithmetic Operations 


Condition Masked Response 


ADDPS, ADDSS, ADDPD, ADDSD, SUBPS, SUBSS, SUBPD, SUBSD, | Return the SNaN converted to a QNaN; Refer to Table 4-7 for 
MULPS, MULSS, MULPD, MULSD, DIVPS, DIVSS, DIVPD, DIVSD, more details 

ADDSUBPD, ADDSUBPD, HADDPD, HADDPS, HSUBPD or HSUBPS 
instruction with an SNaN operand 


SQRTPS, SQRTSS, SQRTPD, or SQRTSD with SNaN operands Return the SNaN converted to a QNaN 


SQRTPS, SORTSS, SQRTPD, or SQRTSD with negative operands | Return the QNaN floating-point Indefinite 
(except zero) 


MAXPS, MAXSS, MAXPD, MAXSD, MINPS, MINSS, MINPD, or Return the source 2 operand value 
MINSD instruction with QNaN or SNaN operands 


CMPPS, CMPSS, CMPPD or CMPSD instruction with QNaN or SNaN | Return a mask of all Os (except for the predicates “not-equal,” 


operands “unordered,” “not-less-than,” or “not-less-than-or-equal,” which 
returns a mask of all 1s) 

CVTPD2PS, CVTSD2SS, CVTPS2PD, CVTSS2SD with SNaN Return the SNaN converted to a QNaN 

operands 

COMISS or COMISD with QNaN or SNaN operand(s) Set EFLAGS values to “not comparable” 


Addition of opposite signed infinities or subtraction of like-signed | Return the QNaN floating-point Indefinite 
infinities 


Multiplication of infinity by zero Return the QNaN floating-point Indefinite 


Divide of (0/0) or ( c¢ / co ) Return the QNaN floating-point Indefinite 


Conversion to integer when the value in the source register isa | Return the integer Indefinite 
NaN, cs, or exceeds the representable range for CVTPS2PI, 
CVTTPS2PI, CVTSS2SI, CVTTSS2SI, CVTPD2PI, CVTSD2SI, 
CVTPD2DQ, CVTTPD2PI, CVTTSD2SI, CVTTPD2DQ, CVTPS2DQ, 
or CVTTPS2DQ 


If the invalid operation exception is not masked, a software exception handler is invoked and the operands remain 
unchanged. See Section 11.5.4, “Handling SIMD Floating-Point Exceptions in Software.” 
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Normally, when one or more of the source operands are QNaNs (and neither is an SNaN or in an unsupported 
format), an invalid-operation exception is not generated. The following instructions are exceptions to this rule: the 
COMISS and COMISD instructions; and the CMPPS, CMPSS, CMPPD, and CMPSD instructions (when the predicate 
is less than, less-than or equal, not less-than, or not less-than or equal). With these instructions, a QNaN source 
operand will generate an invalid-operation exception. 


The invalid-operation exception is not affected by the flush-to-zero mode or by the denormals-are-zeros mode. 


11.5.2.2 Denormal-Operand Exception (#D) 


The processor signals the denormal-operand exception if an arithmetic instruction attempts to operate ona 
denormal operand. The flag (DE) and mask (DM) bits for the denormal-operand exception are bits 1 and 8, respec- 
tively, in the MXCSR register. 


The CVTPI2PD, CVTPD2PI, CVTTPD2PI, CVTDQ2PD, CVTPD2DQ, CVTTPD2DQ, CVTSI2SD, CVTSD2SI, CVTTSD2SI, 
CVTPI2PS, CVTPS2PI, CVTTPS2PI, CVTSS2SI, CVTTSS2SI, CVTSI2SS, CVTDQ2PS, CVTPS2DQ, and CVTTPS2DQ 
conversion instructions do not signal denormal exceptions. The RCPSS, RCPPS, RSQRTSS, and RSQRTPS instruc- 
tions do not signal any kind of floating-point exception. 


The denormals-are-zero flag (bit 6) of the MXCSR register provides an additional option for handling denormal- 
operand exceptions. When this flag is set, denormal source operands are automatically converted to zeros with the 
sign of the source operand (see Section 10.2.3.4, “‘Denormals-Are-Zeros”). The denormal operand exception is not 
affected by the flush-to-zero mode. 


See Section 4.9.1.2, “‘Denormal Operand Exception (#D),” for more information about the denormal exception. 
See Section 11.5.4, “Handling SIMD Floating-Point Exceptions in Software,” for information on handling unmasked 
exceptions. 


11.5.2.3. Divide-By-Zero Exception (#2Z) 


The processor reports a divide-by-zero exception when a DIVPS, DIVSS, DIVPD or DIVSD instruction attempts to 
divide a finite non-zero operand by O. The flag (ZE) and mask (ZM) bits for the divide-by-zero exception are bits 2 
and 9, respectively, in the MXCSR register. 


See Section 4.9.1.3, “Divide-By-Zero Exception (#Z),” for more information about the divide-by-zero exception. 
See Section 11.5.4, “Handling SIMD Floating-Point Exceptions in Software,” for information on handling unmasked 
exceptions. 


The divide-by-zero exception is not affected by the flush-to-zero mode at a single-instruction boundary. 


While DAZ does not affect the rules for signaling IEEE exceptions, operations on denormal inputs might have 
different results when DAZ=1. As a consequence, DAZ can have an effect on the floating-point exceptions - 
including the divide-by-zero exception - when observed for a given operation involving denormal inputs. 


11.5.2.4 Numeric Overflow Exception (#0) 


The processor reports a numeric overflow exception whenever the rounded result of an arithmetic instruction 
exceeds the largest allowable finite value that fits in the destination operand. This exception can be generated with 
the ADDPS, ADDSS, ADDPD, ADDSD, SUBPS, SUBSS, SUBPD, SUBSD, MULPS, MULSS, MULPD, MULSD, DIVPS, 
DIVSS, DIVPD, DIVSD, CVTPD2PS, CVTSD2SS, ADDSUBPD, ADDSUBPS, HADDPD, HADDPS, HSUBPD and HSUBPS 
instructions. The flag (OE) and mask (OM) bits for the numeric overflow exception are bits 3 and 10, respectively, 
in the MXCSR register. 


See Section 4.9.1.4, “Numeric Overflow Exception (#0),” for more information about the numeric-overflow excep- 
tion. See Section 11.5.4, “Handling SIMD Floating-Point Exceptions in Software,” for information on handling 
unmasked exceptions. 


The numeric overflow exception is not affected by the flush-to-zero mode or by the denormals-are-zeros mode. 
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11.5.2.5 Numeric Underflow Exception (#U) 


The processor reports a numeric underflow exception whenever the magnitude of the rounded result of an arith- 
metic instruction, with unbounded exponent, is less than the smallest possible normalized, finite value that will fit 
in the destination operand and the numeric-underflow exception is not masked. If the numeric underflow exception 
is masked, both underflow and the inexact-result condition must be detected before numeric underflow is reported. 
This exception can be generated with the ADDPS, ADDSS, ADDPD, ADDSD, SUBPS, SUBSS, SUBPD, SUBSD, 
MULPS, MULSS, MULPD, MULSD, DIVPS, DIVSS, DIVPD, DIVSD, CVTPD2PS, CVTSD2SS, ADDSUBPD, ADDSUBPS, 
HADDPD, HADDPS, HSUBPD, and HSUBPS instructions. The flag (UE) and mask (UM) bits for the numeric under- 
flow exception are bits 4 and 11, respectively, in the MXCSR register. 


The flush-to-zero flag (bit 15) of the MXCSR register provides an additional option for handling numeric underflow 
exceptions. When this flag is set and the numeric underflow exception is masked, tiny results are returned as a zero 
with the sign of the true result (see Section 10.2.3.3, “Flush-To-Zero”). 


Underflow will occur when a tiny non-zero result is detected (the result has to be also inexact if underflow excep- 
tions are masked), as described in the IEEE Standard 754-2008. While DAZ does not affect the rules for signaling 
IEEE exceptions, operations on denormal inputs might have different results when DAZ=1. As a consequence, DAZ 
can have an effect on the floating-point exceptions - including the underflow exception - when observed for a given 
operation involving denormal inputs. 


See Section 4.9.1.5, “Numeric Underflow Exception (#U),” for more information about the numeric underflow 
exception. See Section 11.5.4, “Handling SIMD Floating-Point Exceptions in Software,” for information on handling 
unmasked exceptions. 


11.5.2.6 Inexact-Result (Precision) Exception (#P) 


The inexact-result exception (also called the precision exception) occurs if the result of an operation is not exactly 
representable in the destination format. For example, the fraction 1/3 cannot be precisely represented in binary 
form. This exception occurs frequently and indicates that some (normally acceptable) accuracy has been lost. The 
exception is supported for applications that need to perform exact arithmetic only. Because the rounded result is 
generally satisfactory for most applications, this exception is commonly masked. 


The flag (PE) and mask (PM) bits for the inexact-result exception are bits 2 and 12, respectively, in the MXCSR 
register. 


See Section 4.9.1.6, “Inexact-Result (Precision) Exception (#P),” for more information about the inexact-result 
exception. See Section 11.5.4, “Handling SIMD Floating-Point Exceptions in Software,” for information on handling 
unmasked exceptions. 


In flush-to-zero mode, the inexact result exception is reported. 


11.5.3. Generating SIMD Floating-Point Exceptions 


When the processor executes a packed or scalar floating-point instruction, it looks for and reports on SIMD 
floating-point exception conditions using two sequential steps: 


1. Looks for, reports on, and handles pre-computation exception conditions (invalid-operand, divide-by-zero, and 
denormal operand) 


2. Looks for, reports on, and handles post-computation exception conditions (numeric overflow, numeric 
underflow, and inexact result) 


If both pre- and post-computational exceptions are unmasked, it is possible for the processor to generate a SIMD 
floating-point exception (#XM) twice during the execution of an SSE, SSE2 or SSE3 instruction: once when it 
detects and handles a pre-computational exception and when it detects a post-computational exception. 


11.5.3.1 Handling Masked Exceptions 


If all exceptions are masked, the processor handles the exceptions it detects by placing the masked result (or 
results for packed operands) in a destination operand and continuing program execution. The masked result may 
be a rounded normalized value, signed infinity, a denormal finite number, zero, a QNaN floating-point indefinite, or 
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a QNaN depending on the exception condition detected. In most cases, the corresponding exception flag bit in 
MXCSR is also set. The one situation where an exception flag is not set is when an underflow condition is detected 
and it is not accompanied by an inexact result. 


When operating on packed floating-point operands, the processor returns a masked result for each of the sub- 
operand computations and sets a separate set of internal exception flags for each computation. It then performs a 
logical-OR on the internal exception flag settings and sets the exception flags in the MXCSR register according to 
the results of OR operations. 


For example, Figure 11-9 shows the results of an MULPS instruction. In the example, all SIMD floating-point excep- 
tions are masked. Assume that a denormal exception condition is detected prior to the multiplication of sub-oper- 
ands XO and YO, no exception condition is detected for the multiplication of X1 and Y1, a numeric overflow 
exception condition is detected for the multiplication of X2 and Y2, and another denormal exception is detected 
prior to the multiplication of sub-operands X3 and Y3. Because denormal exceptions are masked, the processor 
uses the denormal source values in the multiplications of (XO and YO) and of (X3 and Y3) passing the results of the 
multiplications through to the destination operand. With the denormal operand, the result of the XO and YO compu- 
tation is a normalized finite value, with no exceptions detected. However, the X3 and Y3 computation produces a 
tiny and inexact result. This causes the corresponding internal numeric underflow and inexact-result exception 
flags to be set. 


X3 X2 x1 XO (Denormal) 


Y3 (Denormal) Y2 Y1 YO 


Tiny, Inexact, Finite | wm | Normalized Finite} Normalized Finite 


Figure 11-9. Example Masked Response for Packed Operations 


For the multiplication of X2 and Y2, the processor stores the floating-point - in the destination operand, and sets 
the corresponding internal sub-operand numeric overflow flag. The result of the X1 and Y1 multiplication is passed 
through to the destination operand, with no internal sub-operand exception flags being set. Following the compu- 
tations, the individual sub-operand exceptions flags for denormal operand, numeric underflow, inexact result, and 
numeric overflow are OR’d and the corresponding flags are set in the MXCSR register. 


The net result of this computation is that: 

¢ Multiplication of XO and YO produces a normalized finite result 

¢ Multiplication of X1 and Y1 produces a normalized finite result 

¢ Multiplication of X2 and Y2 produces a floating-point result 

¢ Multiplication of X3 and Y3 produces a tiny, inexact, finite result 


¢ Denormal operand, numeric underflow, numeric underflow, and inexact result flags are set in the MXCSR 
register 


11.5.3.2 Handling Unmasked Exceptions 
If all exceptions are unmasked, the processor: 


1. First detects any pre-computation exceptions: it ORs those exceptions, sets the appropriate exception flags, 
leaves the source and destination operands unaltered, and goes to step 2. If it does not detect any pre- 
computation exceptions, it goes to step 5. 
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2. Checks CR4.0SXMMEXCPT[bit 10]. If this flag is set, the processor goes to step 3; if the flag is clear, it 
generates an invalid-opcode exception (#UD) and makes an implicit call to the invalid-opcode exception 
handler. 


3. Generates a SIMD floating-point exception (#XM) and makes an implicit call to the SIMD floating-point 
exception handler. 


4. If the exception handler is able to fix the source operands that generated the pre-computation exceptions or 
mask the condition in such a way as to allow the processor to continue executing the instruction, the processor 
resumes instruction execution as described in step 5. 


5. Upon returning from the exception handler (or if no pre-computation exceptions were detected), the processor 
checks for post-computation exceptions. If the processor detects any post-computation exceptions: it ORs 
those exceptions, sets the appropriate exception flags, leaves the source and destination operands unaltered, 
and repeats steps 2, 3, and 4. 


6. Upon returning from the exceptions handler in step 4 (or if no post-computation exceptions were detected), the 
processor completes the execution of the instruction. 


The implication of this procedure is that for unmasked exceptions, the processor can generate a SIMD floating- 
point exception (#XM) twice: once if it detects pre-computation exception conditions and a second time if it detects 
post-computation exception conditions. For example, if SIMD floating-point exceptions are unmasked for the 
computation shown in Figure 11-9, the processor would generate one SIMD floating-point exception for denormal 
operand conditions and a second SIMD floating-point exception for overflow and underflow (no inexact result 
exception would be generated because the multiplications of XO and YO and of X1 and Yi are exact). 


11.5.3.3. Handling Combinations of Masked and Unmasked Exceptions 


In situations where both masked and unmasked exceptions are detected, the processor will set exception flags for 
the masked and the unmasked exceptions. However, it will not return masked results until after the processor has 
detected and handled unmasked post-computation exceptions and returned from the exception handler (as in step 
6 above) to finish executing the instruction. 


11.5.4 Handling SIMD Floating-Point Exceptions in Software 


Section 4.9.3, “Typical Actions of a Floating-Point Exception Handler,” shows actions that may be carried out by a 
SIMD floating-point exception handler. The SSE/SSE2/SSE3 state is saved with the FXSAVE instruction (see Section 
11.6.5, “Saving and Restoring the SSE/SSE2 State”). 


11.5.5 Interaction of SIMD and x87 FPU Floating-Point Exceptions 


SIMD floating-point exceptions are generated independently from x87 FPU floating-point exceptions. SIMD 
floating-point exceptions do not cause assertion of the FERR# pin (independent of the value of CRO.NE[bit 5]). 
They ignore the assertion and deassertion of the IGNNE#¥ pin. 


If applications use SSE/SSE2/SSE3 instructions along with x87 FPU instructions (in the same task or program), 
consider the following: 


¢ SIMD floating-point exceptions are reported independently from the x87 FPU floating-point exceptions. SIMD 
and x87 FPU floating-point exceptions can be unmasked independently. Separate x87 FPU and SIMD floating- 
point exception handlers must be provided if the same exception is unmasked for x87 FPU and for 
SSE/SSE2/SSE3 operations. 

¢ The rounding mode specified in the MXCSR register does not affect x87 FPU instructions. Likewise, the rounding 
mode specified in the x87 FPU control word does not affect the SSE/SSE2/SSE3 instructions. To use the same 
rounding mode, the rounding control bits in the MXCSR register and in the x87 FPU control word must be set 
explicitly to the same value. 

¢ The flush-to-zero mode set in the MXCSR register for SSE/SSE2/SSE3 instructions has no counterpart in the 
x87 FPU. For compatibility with the x87 FPU, set the flush-to-zero bit to 0. 
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¢ The denormals-are-zeros mode set in the MXCSR register for SSE/SSE2/SSE3 instructions has no counterpart 
in the x87 FPU. For compatibility with the x87 FPU, set the denormals-are-zeros bit to 0. 


¢ An application that expects to detect x87 FPU exceptions that occur during the execution of x87 FPU instruc- 
tions will not be notified if exceptions occurs during the execution of corresponding SSE/SSE2/SSE3? instruc- 
tions, unless the exception masks that are enabled in the x87 FPU control word have also been enabled in the 
MXCSR register and the application is capable of handling SIMD floating-point exceptions (#XM). 


— Masked exceptions that occur during an SSE/SSE2/SSE3 library call cannot be detected by unmasking the 
exceptions after the call (in an attempt to generate the fault based on the fact that an exception flag is set). 
A SIMD floating-point exception flag that is set when the corresponding exception is unmasked will not 
generate a fault; only the next occurrence of that unmasked exception will generate a fault. 


— An application which checks the x87 FPU status word to determine if any masked exception flags were set 
during an x87 FPU library call will also need to check the MXCSR register to detect a similar occurrence of a 
masked exception flag being set during an SSE/SSE2/SSE3 library call. 


11.6 WRITING APPLICATIONS WITH SSE/SSE2 EXTENSIONS 


The following sections give some guidelines for writing application programs and operating-system code that uses 
the SSE and SSE2 extensions. Because SSE and SSE2 extensions share the same state and perform companion 
operations, these guidelines apply to both sets of extensions. 


Chapter 13 in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, discusses the inter- 
face to the processor for context switching as well as other operating system considerations when writing code that 
uses SSE/SSE2/SSE3 extensions. 


11.6.1 General Guidelines for Using SSE/SSE2 Extensions 


The following guidelines describe how to take full advantage of the performance gains available with the SSE and 
SSE2 extensions: 


¢ Ensure that the processor supports the SSE and SSE2 extensions. 


¢ Ensure that your operating system supports the SSE and SSE2 extensions. (Operating system support for the 
SSE extensions implies support for SSE2 extension and vice versa.) 


¢ Use stack and data alignment techniques to keep data properly aligned for efficient memory use. 
¢ Use the non-temporal store instructions offered with the SSE and SSE2 extensions. 


¢ Employ the optimization and scheduling techniques described in the Intel Pentium 4 Optimization Reference 
Manual (see Section 1.4, “Related Literature,” for the order number for this manual). 


11.6.2 Checking for SSE/SSE2 Support 


Before an application attempts to use the SSE and/or SSE2 extensions, it should check that they are present on the 
processor: 


1. Check that the processor supports the CPUID instruction. Bit 21 of the EFLAGS register can be used to check 
processor’s support the CPUID instruction. 


2. Check that the processor supports the SSE and/or SSE2 extensions (true if CPUID.OLH:EDX.SSE[bit 25] = 1 
and/or CPUID.01H:EDX.SSE2[bit 26] = 1). 


Operating system must provide system level support for handling SSE state, exceptions before an application can 
use the SSE and/or SSE2 extensions (see Chapter 13 in the Intel® 64 and IA-32 Architectures Software Devel- 
oper’s Manual, Volume 3A). 


1. SSE€3 refers to ADDSUBPD, ADDSUBPS, HADDPD, HADDPS, HSUBPD and HSUBPS; the only other SSE3 instruction that can raise 
floating-point exceptions is FISTTP: it can generate x87 FPU invalid operation and inexact result exceptions. 
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If the processor attempts to execute an unsupported SSE or SSE2 instruction, the processor will generate an 
invalid-opcode exception (#UD). If an operating system did not provide adequate system level support for SSE, 
executing an SSE or SSE2 instructions can also generate #UD. 


11.6.3. Checking for the DAZ Flag in the MXCSR Register 


The denormals-are-zero flag in the MXCSR register is available in most of the Pentium 4 processors and in the Intel 
Xeon processor, with the exception of some early steppings. To check for the presence of the DAZ flag in the MKCSR 
register, do the following: 


1. Establish a 512-byte FXSAVE area in memory. 
2. Clear the FXSAVE area to all Os. 


3. Execute the FXSAVE instruction, using the address of the first byte of the cleared FXSAVE area as a source 
operand. See “FXSAVE—Save x87 FPU, MMX, SSE, and SSE2 State” in Chapter 3 of the Inte/® 64 and IA-32 
Architectures Software Developer’s Manual, Volume 2A, for a description of the FXSAVE instruction and the 
layout of the FXSAVE image. 


4. Check the value in the MKCSR_MASK field in the FXSAVE image (bytes 28 through 31). 


— If the value of the MXCSR_MASK field is OOOOOO00H, the DAZ flag and denormals-are-zero mode are not 
supported. 


— If the value of the MXCSR_MASK field is non-zero and bit 6 is set, the DAZ flag and denormals-are-zero 
mode are supported. 


If the DAZ flag is not supported, then it is a reserved bit and attempting to write a 1 to it will cause a general- 
protection exception (#GP). See Section 11.6.6, “Guidelines for Writing to the MXCSR Register,” for general guide- 
lines for preventing general-protection exceptions when writing to the MXCSR register. 


11.6.4 Initialization of SSE/SSE2 Extensions 


The SSE and SSE2 state is contained in the XMM and MXCSR registers. Upon a hardware reset of the processor, this 
state is initialized as follows (see Table 11-2): 


¢ All SIMD floating-point exceptions are masked (bits 7 through 12 of the MXCSR register is set to 1). 

¢ All SIMD floating-point exception flags are cleared (bits 0 through 5 of the MXCSR register is set to 0). 
¢ The rounding control is set to round-nearest (bits 13 and 14 of the MXCSR register are set to OOB). 

¢ The flush-to-zero mode is disabled (bit 15 of the MXCSR register is set to 0). 


¢ The denormals-are-zeros mode is disabled (bit 6 of the MXCSR register is set to 0). If the denormals-are-zeros 
mode is not supported, this bit is reserved and will be set to 0 on initialization. 


¢ Each of the XMM registers is cleared (set to all zeros). 


Table 11-2. SSE and SSE2 State Following a Power-up/Reset or INIT 


Registers Power-Up or Reset INIT 
XMMO through XMM7 +0.0 Unchanged 
MXCSR 1F80H Unchanged 


If the processor is reset by asserting the INIT# pin, the SSE and SSE2 state is not changed. 


11.6.5 Saving and Restoring the SSE/SSE2 State 


The FXSAVE instruction saves the x87 FPU, MMX, SSE and SSE2 states (which includes the contents of eight XMM 
registers and the MXCSR registers) in a 512-byte block of memory. The FXRSTOR instruction restores the saved 
SSE and SSE2 state from memory. See the FXSAVE instruction in Chapter 3 of the Inte/® 64 and IA-32 Architec- 
tures Software Developer’s Manual, Volume 2A, for the layout of the 512-byte state block. 


11-20 Vol. 1 


PROGRAMMING WITH INTEL® STREAMING SIMD EXTENSIONS 2 (INTEL® SSE2) 


In addition to saving and restoring the SSE and SSE2 state, FXSAVE and FXRSTOR also save and restore the x87 
FPU state (because MMX registers are aliased to the x87 FPU data registers this includes saving and restoring the 
MMX state). For greater code efficiency, it is suggested that FXSAVE and FXRSTOR be substituted for the FSAVE, 
FNSAVE and FRSTOR instructions in the following situations: 


¢ When a context switch is being made in a multitasking environment 
® During calls and returns from interrupt and exception handlers 


In situations where the code is switching between x87 FPU and MMX technology computations (without a context 
switch or a call to an interrupt or exception), the FSAVE/FNSAVE and FRSTOR instructions are more efficient than 
the FXSAVE and FXRSTOR instructions. 


11.6.6 Guidelines for Writing to the MXCSR Register 


The MXCSR has several reserved bits, and attempting to write a 1 to any of these bits will cause a general-protec- 
tion exception (#GP) to be generated. To allow software to identify these reserved bits, the MKCSR_MASK value is 
provided. Software can determine this mask value as follows: 


1. Establish a 512-byte FXSAVE area in memory. 
2. Clear the FXSAVE area to all Os. 


3. Execute the FXSAVE instruction, using the address of the first byte of the cleared FXSAVE area as a source 
operand. See “FXSAVE—Save x87 FPU, MMX, SSE, and SSE2 State” in Chapter 3 of the Inte/® 64 and IA-32 
Architectures Software Developer’s Manual, Volume 2A, for a description of FXSAVE and the layout of the 
FXSAVE image. 


4. Check the value in the MKCSR_MASK field in the FXSAVE image (bytes 28 through 31). 


— Ifthe value of the MKCSR_MASK field is OOOOOO00H, then the MXCSR_MASK value is the default value of 
OOOOFFBFH. Note that this value indicates that bit 6 of the MXCSR register is reserved; this setting indicates 
that the denormals-are-zero mode is not supported on the processor. 


— Ifthe value of the MKCSR_MASK field is non-zero, the MKCSR_MASK value should be used as the 
MXCSR_MASK. 


All bits set to 0 in the MKCSR_MASK value indicate reserved bits in the MXCSR register. Thus, if the MKCSR_MASK 
value is AND’d with a value to be written into the MXCSR register, the resulting value will be assured of having all 
its reserved bits set to 0, preventing the possibility of a general-protection exception being generated when the 
value is written to the MXCSR register. 


For example, the default MKCSR_MASK value when OOOOOOOOH is returned in the FXSAVE image is OOOOFFBFH. If 
software AND’s a value to be written to MXCSR register with OOOOFFBFH, bit 6 of the result (the DAZ flag) will be 
ensured of being set to 0, which is the required setting to prevent general-protection exceptions on processors that 
do not support the denormals-are-zero mode. 


To prevent general-protection exceptions, the MKCSR_MASK value should be AND’d with the value to be written 
into the MXCSR register in the following situations: 


* Operating system routines that receive a parameter from an application program and then write that value to 
the MXCSR register (either with an FXRSTOR or LDMXCSR instruction) 


¢ Any application program that writes to the MXCSR register and that needs to run robustly on several different 
IA-32 processors 


Note that all bits in the MXCSR_MASK value that are set to 1 indicate features that are supported by the MXCSR 
register; they can be treated as feature flags for identifying processor capabilities. 


11.6.7. —_ Interaction of SSE/SSE2 Instructions with x87 FPU and MMxX Instructions 


The XMM registers and the x87 FPU and MMX registers represent separate execution environments, which has 
certain ramifications when executing SSE, SSE2, MMX, and x87 FPU instructions in the same code module or when 
mixing code modules that contain these instructions: 
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¢ Those SSE and SSE2 instructions that operate only on XMM registers (such as the packed and scalar floating- 
point instructions and the 128-bit SIMD integer instructions) in the same instruction stream with 64-bit SIMD 
integer or x87 FPU instructions without any restrictions. For example, an application can perform the majority 
of its floating-point computations in the XMM registers, using the packed and scalar floating-point instructions, 
and at the same time use the x87 FPU to perform trigonometric and other transcendental computations. 
Likewise, an application can perform packed 64-bit and 128-bit SIMD integer operations together without 
restrictions. 


¢ Those SSE and SSE2 instructions that operate on MMX registers (such as the CVTPS2PI, CVTTPS2PI, CVTPI2PS, 
CVTPD2PI, CVTTPD2PI, CVTPIZ2PD, MOVDQ2Q, MOVQ2DQ, PADDQ, and PSUBQ instructions) can also be 
executed in the same instruction stream as 64-bit SIMD integer or x87 FPU instructions, however, here they are 
subject to the restrictions on the simultaneous use of MMX technology and x87 FPU instructions, which include: 


— Transition from x87 FPU to MMX technology instructions or to SSE or SSE2 instructions that operate on MMX 
registers should be preceded by saving the state of the x87 FPU. 


— Transition from MMX technology instructions or from SSE or SSE2 instructions that operate on MMX 
registers to x87 FPU instructions should be preceded by execution of the EMMS instruction. 


11.6.8 Compatibility of SIMD and x87 FPU Floating-Point Data Types 


SSE and SSE2 extensions operate on the same single-precision and double-precision floating-point data types that 
the x87 FPU operates on. However, when operating on these data types, the SSE and SSE2 extensions operate on 
them in their native format (single-precision or double-precision), in contrast to the x87 FPU which extends them 
to double extended-precision floating-point format to perform computations and then rounds the result back to a 
single-precision or double-precision format before writing results to memory. Because the x87 FPU operates on a 
higher precision format and then rounds the result to a lower precision format, it may return a slightly different 
result when performing the same operation on the same single-precision or double-precision floating-point values 
than is returned by the SSE and SSE2 extensions. The difference occurs only in the least-significant bits of the 
significand. 


11.6.9 Mixing Packed and Scalar Floating-Point and 128-Bit SIMD Integer Instructions and 
Data 


SSE and SSE2 extensions define typed operations on packed and scalar floating-point data types and on 128-bit 
SIMD integer data types, but IA-32 processors do not enforce this typing at the architectural level. They only 
enforce it at the microarchitectural level. Therefore, when a Pentium 4 or Intel Xeon processor loads a packed or 
scalar floating-point operand or a 128-bit packed integer operand from memory into an XMM register, it does not 
check that the actual data being loaded matches the data type specified in the instruction. Likewise, when the 
processor performs an arithmetic operation on the data in an XMM register, it does not check that the data being 
operated on matches the data type specified in the instruction. 


As a general rule, because data typing of SIMD floating-point and integer data types is not enforced at the archi- 
tectural level, it is the responsibility of the programmer, assembler, or compiler to ensure that code enforces data 
typing. Failure to enforce correct data typing can lead to computations that return unexpected results. 


For example, in the following code sample, two packed single-precision floating-point operands are moved from 
memory into XMM registers (using MOVAPS instructions); then a double-precision packed add operation (using the 
ADDPD instruction) is performed on the operands: 


movaps xmm0, [eax] ;€AX register contains pointer to packed 
; single-precision floating-point operand 

movaps xmm1, [ebx] 

addpd xmmo, xmm1 


Pentium 4 and Intel Xeon processors execute these instructions without generating an invalid-operand exception 

(#UD) and will produce the expected results in register XMMO (that is, the high and low 64-bits of each register will 
be treated as a double-precision floating-point value and the processor will operate on them accordingly). Because 
the data types operated on and the data type expected by the ADDPD instruction were inconsistent, the instruction 
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may result in a SIMD floating-point exception (such as numeric overflow [#0] or invalid operation [#I]) being 
generated, but the actual source of the problem (inconsistent data types) is not detected. 


The ability to operate on an operand that contains a data type that is inconsistent with the typing of the instruction 
being executed, permits some valid operations to be performed. For example, the following instructions load a 
packed double-precision floating-point operand from memory to register XMMO, and a mask to register XMM1; 
then they use XORPD to toggle the sign bits of the two packed values in register XMMO. 


movapd xmm0, [eax] ; €AX register contains pointer to packed 
; double-precision floating-point operand 
movaps xmm1,[ebx] ; EBX register contains pointer to packed 
; double-precision floating-point mask 
xorpd xmm0O, xmm1_; XOR operation toggles sign bits using 
; the mask in xmm1 


In this example: XORPS or PXOR can be used in place of XORPD and yield the same correct result. However, 
because of the type mismatch between the operand data type and the instruction data type, a latency penalty will 
be incurred due to implementations of the instructions at the microarchitecture level. 


Latency penalties can also be incurred by using move instructions of the wrong type. For example, MOVAPS and 
MOVAPD can both be used to move a packed single-precision operand from memory to an XMM register. However, 
if MOVAPD is used, a latency penalty will be incurred when a correctly typed instruction attempts to use the data in 
the register. 


Note that these latency penalties are not incurred when moving data from XMM registers to memory. 


11.6.10 Interfacing with SSE/SSE2 Procedures and Functions 


SSE and SSE2 extensions allow direct access to XMM registers. This means that all existing interface conventions 
between procedures and functions that apply to the use of the general-purpose registers (EAX, EBX, etc.) also 
apply to XMM register usage. 


11.6.10.1 Passing Parameters in XMM Registers 


The state of XMM registers is preserved across procedure (or function) boundaries. Parameters can be passed from 
one procedure to another using XMM registers. 


11.6.10.2 Saving XMM Register State on a Procedure or Function Call 


The state of XMM registers can be saved in two ways: using an FXSAVE instruction or a move instruction. FXKSAVE 
saves the state of all XMM registers (along with the state of MXCSR and the x87 FPU registers). This instruction is 
typically used for major changes in the context of the execution environment, such as a task switch. FXRSTOR 
restores the XMM, MXCSR, and x87 FPU registers stored with FXSAVE. 


In cases where only XMM registers must be saved, or where selected XMM registers need to be saved, move 
instructions (MOVAPS, MOVUPS, MOVSS, MOVAPD, MOVUPD, MOVSD, MOVDQA, and MOVDQU) can be used. 
These instructions can also be used to restore the contents of XMM registers. To avoid performance degradation 
when saving XMM registers to memory or when loading XMM registers from memory, be sure to use the appropri- 
ately typed move instructions. 


The move instructions can also be used to save the contents of XMM registers on the stack. Here, the stack pointer 
(in the ESP register) can be used as the memory address to the next available byte in the stack. Note that the stack 
pointer is not automatically incremented when using a move instruction (as it is with PUSH). 


A move-instruction procedure that saves the contents of an XMM register to the stack is responsible for decre- 
menting the value in the ESP register by 16. Likewise, a move-instruction procedure that loads an XMM register 
from the stack needs also to increment the ESP register by 16. To avoid performance degradation when moving the 
contents of XMM registers, use the appropriately typed move instructions. 
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Use the LDMXCSR and STMXCSR instructions to save and restore, respectively, the contents of the MXCSR register 
on a procedure call and return. 


11.6.10.3 Caller-Save Recommendation for Procedure and Function Calls 


When making procedure (or function) calls from SSE or SSE2 code, a caller-save convention is recommended for 
saving the state of the calling procedure. Using this convention, any register whose content must survive intact 
across a procedure call must be stored in memory by the calling procedure prior to executing the call. 


The primary reason for using the caller-save convention is to prevent performance degradation. XMM registers can 
contain packed or scalar double-precision floating-point, packed single-precision floating-point, and 128-bit packed 
integer data types. The called procedure has no way of knowing the data types in XMM registers following a call; so 
it is unlikely to use the correctly typed move instruction to store the contents of XMM registers in memory or to 
restore the contents of XMM registers from memory. 


As described in Section 11.6.9, “Mixing Packed and Scalar Floating-Point and 128-Bit SIMD Integer Instructions 
and Data,” executing a move instruction that does not match the type for the data being moved to/from XMM regis- 
ters will be carried out correctly, but can lead to a greater instruction latency. 


11.6.11 Updating Existing MMX Technology Routines Using 128-Bit SIMD Integer Instructions 


SSE2 extensions extend all 64-bit MMX SIMD integer instructions to operate on 128-bit SIMD integers using XMM 
registers. The extended 128-bit SIMD integer instructions operate like the 64-bit SIMD integer instructions; this 
simplifies the porting of MMX technology applications. However, there are considerations: 


* To take advantage of wider 128-bit SIMD integer instructions, MMX technology code must be recompiled to 
reference the XMM registers instead of MMX registers. 


* Computation instructions that reference memory operands that are not aligned on 16-byte boundaries should 
be replaced with an unaligned 128-bit load (MOVUDQ instruction) followed by a version of the same 
computation operation that uses register instead of memory operands. Use of 128-bit packed integer 
computation instructions with memory operands that are not 16-byte aligned results in a general protection 
exception (#GP). 


° Extension of the PSHUFW instruction (shuffle word across 64-bit integer operand) across a full 128-bit operand 
is emulated by a combination of the following instructions: PGHUFHW, PSHUFLW, and PSHUFD. 


e  =Use of the 64-bit shift by bit instructions (PSRLQ, PSLLQ) can be extended to 128 bits in either of two ways: 
— Use of PSRLQ and PSLLQ, along with masking logic operations. 
— Rewriting the code sequence to use PSRLDQ and PSLLDQ (shift double quadword operand by bytes) 


¢ Loop counters need to be updated, since each 128-bit SIMD integer instruction operates on twice the amount 
of data as its 64-bit SIMD integer counterpart. 


11.6.12 Branching on Arithmetic Operations 


There are no condition codes in SSE or SSE2 states. A packed-data comparison instruction generates a mask which 
can then be transferred to an integer register. The following code sequence provides an example of how to perform 
a conditional branch, based on the result of an SSE2 arithmetic operation. 


cmppd XMMO, XMM1 ; generates a mask in XMMO 
movmskpd EAX, XMMO ;moves a 2 bit mask to eax 
test EAX, 0 ; compare with desired result 
jne BRANCH TARGET 


The COMISD and UCOMISD instructions update the EFLAGS as the result of a scalar comparison. A conditional 
branch can then be scheduled immediately following COMISD/UCOMISD. 
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11.6.13 Cacheability Hint Instructions 


SSE and SSE2 cacheability control instructions enable the programmer to control prefetching, caching, loading and 
storing of data. When correctly used, these instructions improve application performance. 


To make efficient use of the processor’s super-scalar microarchitecture, a program needs to provide a steady 
stream of data to the executing program to avoid stalling the processor. PREFETCHA instructions minimize the 
latency of data accesses in performance-critical sections of application code by allowing data to be fetched into the 
processor cache hierarchy in advance of actual usage. 


PREFETCHA instructions do not change the user-visible semantics of a program, although they may affect perfor- 
mance. The operation of these instructions is implementation-dependent. Programmers may need to tune code for 
each IA-32 processor implementation. Excessive usage of PREFETCHhA instructions may waste memory bandwidth 
and reduce performance. For more detailed information on the use of prefetch hints, refer to Chapter 7, “Opti- 
mizing Cache Usage,”, in the Inte/® 64 and IA-32 Architectures Optimization Reference Manual. 


The non-temporal store instructions (MOVNTI, MOVNTPD, MOVNTPS, MOVNTDQ, MOVNTQ, MASKMOVQ, and 
MASKMOVDQU) minimize cache pollution when writing non-temporal data to memory (see Section 10.4.6.1, 
“Cacheability Control Instructions” and Section 10.4.6.2, “Caching of Temporal vs. Non-Temporal Data”). They 
prevent non-temporal data from being written into processor caches on a store operation. 


Besides reducing cache pollution, the use of weakly-ordered memory types can be important under certain data 
sharing relationships, such as a producer-consumer relationship. The use of weakly ordered memory can make the 
assembling of data more efficient; but care must be taken to ensure that the consumer obtains the data that the 
producer intended. Some common usage models that may be affected in this way by weakly-ordered stores are: 


¢ Library functions that use weakly ordered memory to write results 
* Compiler-generated code that writes weakly-ordered results 
° Hand-crafted code 


The degree to which a consumer of data knows that the data is weakly ordered can vary for these cases. As a 
result, the SFENCE or MFENCE instruction should be used to ensure ordering between routines that produce 
weakly-ordered data and routines that consume the data. SFENCE and MFENCE provide a performance-efficient 
way to ensure ordering by guaranteeing that every store instruction that precedes SFENCE/MFENCE in program 
order is globally visible before a store instruction that follows the fence. 


11.6.14 Effect of Instruction Prefixes on the SSE/SSE2 Instructions 


Table 11-3 describes the effects of instruction prefixes on SSE and SSE2 instructions. (Table 11-3 also applies to 

SIMD integer and SIMD floating-point instructions in SSE3.) Unpredictable behavior can range from prefixes being 
treated as a reserved operation on one generation of IA-32 processors to generating an invalid opcode exception 
on another generation of processors. 


See also “Instruction Prefixes” in Chapter 2 of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 2A, for complete description of instruction prefixes. 


NOTE 


Some SSE/SSE2/SSE3 instructions have two-byte opcodes that are either 2 bytes or 3 bytes in 
length. Two-byte opcodes that are 3 bytes in length consist of: a mandatory prefix (F2H, F3H, or 
66H), OFH, and an opcode byte. See Table 11-3. 
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Table 11-3. Effect of Prefixes on SSE, SSE2, and SSE3 Instructions 


Prefix Type Effect on SSE, SSE2 and SSE3 Instructions 
Address Size Prefix (67H) Affects instructions with a memory operand. 
Reserved for instructions without a memory operand and may result in unpredictable 
behavior. 
Operand Size (66H) Reserved and may result in unpredictable behavior. 
Segment Override Affects instructions with a memory operand. 
(2EH,36H,3EH,26H,64H,65H) 


Reserved for instructions without a memory operand and may result in unpredictable 
behavior. 


Repeat Prefixes (F2H and F3H) 


Reserved and may result in unpredictable behavior. 


Lock Prefix (FOH) 


Reserved; generates invalid opcode exception (HUD). 


Branch Hint Prefixes(E2H and E3H) 


Reserved and may result in unpredictable behavior. 
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CHAPTER 12 
PROGRAMMING WITH INTEL® SSE3, SSSE3, 
INTEL® SSE4 AND INTEL® AESNI 


This chapter describes SSE3, SSSE3, SSE4 and provides information to assist in writing application programs that 
use these extensions. 


AESNI and PCLMLQDQ are instruction extensions targeted to accelerate high-speed block encryption and crypto- 
graphic processing. Section 12.13 covers these instructions and their relationship to the Advanced Encryption 
Standard (AES). 


12.1 PROGRAMMING ENVIRONMENT AND DATA TYPES 


The programming environment for using SSE3, SSSE3, and SSE4 is unchanged from those shown in Figure 3-1 and 
Figure 3-2. SSE3, SSSE3, and SSE4 do not introduce new data types. XMM registers are used to operate on packed 
integer data, single-precision floating-point data, or double-precision floating-point data. 


One SSE3 instruction uses the x87 FPU for x87-style programming. There are two SSE3 instructions that use the 
general registers for thread synchronization. The MXCSR register governs SIMD floating-point operations. Note, 
however, that the x87FPU control word does not affect the SSE3 instruction that is executed by the x87 FPU 
(FISTTP), other than by unmasking an invalid operand or inexact result exception. 


SSE4 instructions do not use MMX registers. The majority of SSE4.2! instructions and SSE4.1 instructions operate 
on XMM registers. 


12.1.1 SSE3, SSSE3, SSE4 in 64-Bit Mode and Compatibility Mode 


In compatibility mode, SSE3, SSSE3, and SSE4 function like they do in protected mode. In 64-bit mode, eight addi- 
tional XMM registers are accessible. Registers XMM8-XMM15 are accessed by using REX prefixes. 


Memory operands are specified using the ModR/M, SIB encoding described in Section 3.7.5. 


Some SSE3, SSSE3, and SSE4 instructions may be used to operate on general-purpose registers. Use the REX.W 
prefix to access 64-bit general-purpose registers. Note that if a REX prefix is used when it has no meaning, the 
prefix is ignored. 


12.1.2 Compatibility of SSE3/SSSE3 with MMX Technology, the x87 FPU Environment, and 
SSE/SSE2 Extensions 
SSE3, SSSE3, and SSE4 do not introduce any new state to the Intel 64 and IA-32 execution environments. 


For SIMD and x87 programming, the FXSAVE and FXRSTOR instructions save and restore the architectural states 
of XMM, MXCSR, x87 FPU, and MMX registers. The MONITOR and MWAIT instructions use general purpose registers 
on input, they do not modify the content of those registers. 


12.1.3. Horizontal and Asymmetric Processing 


Many SSE/SSE2/SSE3/SSSE3 instructions accelerate SIMD data processing using a model referred to as vertical 
computation. Using this model, data flow is vertical between the data elements of the inputs and the output. 


Figure 12-1 illustrates the asymmetric processing of the SSE3 instruction ADDSUBPD. Figure 12-2 illustrates the 
horizontal data movement of the SSE3 instruction HADDPD. 


1. Although the presence of CRC32 support is enumerated by CPUID.01:ECX[SSE4.2] = 1, CRC32 operates on general purpose regis- 
ters. 
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Figure 12-1. Asymmetric Processing in ADDSUBPD 
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Figure 12-2. Horizontal Data Movement in HADDPD 


12.2 OVERVIEW OF SSE3 INSTRUCTIONS 


SSE3 extensions include 13 instructions. See: 


® Section 12.3, “SSE3 Instructions,” provides an introduction to individual SSE3 instructions. 
° Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A & 2B, provide detailed 


information on individual instructions. 


¢ Chapter 13, “System Programming for Instruction Set Extensions and Processor Extended States,” in the 
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, gives guidelines for integrating 


SSE/SSE2/SSE3 extensions into an operating-system environment. 


12.3. SSE3 INSTRUCTIONS 


SSE3 instructions are grouped as follows: 
¢ ~=x87 FPU instruction 


— One instruction that improves x87 FPU floating-point to integer conversion 


¢ SIMD integer instruction 
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— One instruction that provides a specialized 128-bit unaligned data load 
¢ SIMD floating-point instructions 

— Three instructions that enhance LOAD/MOVE/DUPLICATE performance 

— ‘Two instructions that provide packed addition/subtraction 

— Four instructions that provide horizontal addition/subtraction 
¢ Thread synchronization instructions 

— Two instructions that improve synchronization between multi-threaded agents 
The instructions are discussed in more detail in the following paragraphs. 


12.3.1. x87 FPU Instruction for Integer Conversion 


The FISTTP instruction (x87 FPU Store Integer and Pop with Truncation) behaves like FISTP, but uses truncation 
regardless of what rounding mode is specified in the x87 FPU control word. The instruction converts the top of stack 
(STO) to integer with rounding to and pops the stack. 


The FISTTP instruction is available in three precisions: short integer (word or 16-bit), integer (double word or 32- 
bit), and long integer (64-bit). With FISTTP, applications no longer need to change the FCW when truncation is 
required. 


12.3.2 SIMD Integer Instruction for Specialized 128-bit Unaligned Data Load 


The LDDQU instruction is a special 128-bit unaligned load designed to avoid cache line splits. If the address of a 16- 
byte load is on a 16-byte boundary, LDQQU loads the bytes requested. If the address of the load is not aligned on 
a 16-byte boundary, LDDQU loads a 32-byte block starting at the 16-byte aligned address immediately below the 
load request. It then extracts the requested 16 bytes. 


The instruction provides significant performance improvement on 128-bit unaligned memory accesses at the cost 
of some usage model restrictions. 


12.3.3. SIMD Floating-Point Instructions That Enhance LOAD/MOVE/DUPLICATE Performance 
The MOVSHDUP instruction loads/moves 128-bits, duplicating the second and fourth 32-bit data elements. 
¢ MOVSHDUP OperandA, OperandB 
— OperandA (128 bits, four data elements): 33, 23, 1a, O3 
— OperandB (128 bits, four data elements): 3p, 2p, 1p, Op 
— Result (stored in OperandA): 3p, 3p, 1b, 1p 
The MOVSLDUP instruction loads/moves 128-bits, duplicating the first and third 32-bit data elements. 
¢ MOVSLDUP OperandA, OperandB 
— OperandA (128 bits, four data elements): 33, 23, 1a, 03 
— OperandB (128 bits, four data elements): 3p, 2p, 1b, Op 
— Result (stored in OperandA): 25, 2p, Op, Op 
The MOVDDUP instruction loads/moves 64-bits; duplicating the 64 bits from the source. 
¢ MOVDDUP OperandA, OperandB 
— OperandA (128 bits, two data elements): 1,, 0, 
— OperandB (64 bits, one data element): O, 
— Result (stored in OperandA): Op, Op 
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12.3.4 SIMD Floating-Point Instructions Provide Packed Addition/Subtraction 


The ADDSUBPS instruction has two 128-bit operands. The instruction performs single-precision addition on the 
second and fourth pairs of 32-bit data elements within the operands; and single-precision subtraction on the first 
and third pairs. 


¢ ADDSUBPS OperandA, OperandB 
— OperandA (128 bits, four data elements): 33, 23, 13, 0, 
— OperandB (128 bits, four data elements): 3p, 2p, 1p, Op 
— Result (stored in OperandA): 33+3p, 29-2, 1la+1p, 0a-Op 


The ADDSUBPD instruction has two 128-bit operands. The instruction performs double-precision addition on the 
second pair of quadwords, and double-precision subtraction on the first pair. 


¢ ADDSUBPD OperandA, OperandB 
— OperandA (128 bits, two data elements): 1,, 0, 
— OperandB (128 bits, two data elements): 1p, Op 
— Result (stored in OperandA): 13+1p, 03-Op 


12.3.5 SIMD Floating-Point Instructions Provide Horizontal Addition/Subtraction 


Most SIMD instructions operate vertically. This means that the result in position i is a function of the elements in 
position i of both operands. Horizontal addition/subtraction operates horizontally. This means that contiguous data 
elements in the same source operand are used to produce a result. 


The HADDPS instruction performs a single-precision addition on contiguous data elements. The first data element 
of the result is obtained by adding the first and second elements of the first operand; the second element by adding 
the third and fourth elements of the first operand; the third by adding the first and second elements of the second 
operand; and the fourth by adding the third and fourth elements of the second operand. 


¢ HADDPS OperandA, OperandB 
— OperandA (128 bits, four data elements): 33, 23, 1a, Oa 
— OperandB (128 bits, four data elements): 3p, 2p, 1p, Op 
— Result (Stored in OperandA): 3p+2p, 1p+0p, 33+2a, 1a+0a 


The HSUBPS instruction performs a single-precision subtraction on contiguous data elements. The first data 
element of the result is obtained by subtracting the second element of the first operand from the first element of 
the first operand; the second element by subtracting the fourth element of the first operand from the third element 
of the first operand; the third by subtracting the second element of the second operand from the first element of 
the second operand; and the fourth by subtracting the fourth element of the second operand from the third 
element of the second operand. 


¢ HSUBPS OperandA, OperandB 
— OperandA (128 bits, four data elements): 33, 2a, 1a, Oa 
— OperandB (128 bits, four data elements): 3p, 2p, 1p, Op 
— Result (Stored in OperandA): 24-3), Op-1p, 24-34, Oa-1a 


The HADDPD instruction performs a double-precision addition on contiguous data elements. The first data element 
of the result is obtained by adding the first and second elements of the first operand; the second element by adding 
the first and second elements of the second operand. 


¢ HADDPD OperandA, OperandB 
— OperandA (128 bits, two data elements): 1,, 05 
— OperandB (128 bits, two data elements): 1p, Op 
— Result (Stored in OperandA): 1,+0,, 1,+0, 
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The HSUBPD instruction performs a double-precision subtraction on contiguous data elements. The first data 
element of the result is obtained by subtracting the second element of the first operand from the first element of 
the first operand; the second element by subtracting the second element of the second operand from the first 
element of the second operand. 


¢ HSUBPD OperandA OperandB 
— OperandA (128 bits, two data elements): 13, 03 
— OperandB (128 bits, two data elements): 1p, Op 
— Result (Stored in OperandA): Op-1p, 03-15 


12.3.6 Two Thread Synchronization Instructions 
The MONITOR instruction sets up an address range that is used to monitor write-back-stores. 


MWAIT enables a logical processor to enter into an optimized state while waiting for a write-back-store to the 
address range set up by MONITOR. MONITOR and MWAIT require the use of general purpose registers for its input. 
The registers used by MONITOR and MWAIT must be initialized properly; register content is not modified by these 
instructions. 


12.4 WRITING APPLICATIONS WITH SSE3 EXTENSIONS 


The following sections give guidelines for writing application programs and operating-system code that use SSE3 
instructions. 


12.4.1 Guidelines for Using SSE3 Extensions 
The following guidelines describe how to maximize the benefits of using SSE3 extensions: 
° Check that the processor supports SSE3 extensions. 


— Application may need to ensure that the target operating system supports SSE3. (Operating system 
support for the SSE extensions implies sufficient support for SSE2 extensions and SSE3 extensions.) 


¢ Ensure your operating system supports MONITOR and MWAIT. 


¢ Employ the optimization and scheduling techniques described in the Intel® 64 and IA-32 Architectures Optimi- 
zation Reference Manual (see Section 1.4, “Related Literature”). 


12.4.2 Checking for SSE3 Support 


Before an application attempts to use the SIMD subset of SSE3 extensions, the application should follow the steps 
illustrated in Section 11.6.2, “Checking for SSE/SSE2 Support.” Next, use the additional step provided below: 


¢ Check that the processor supports the SIMD and x87 SSE3 extensions (if CPUID.01H:ECX.SSE3[bit 0] = 1). 


An operating systems that provides application support for SSE, SSE2 also provides sufficient application support 
for SSE3. To use FISTTP, software only needs to check support for SSE3. 


In the initial implementation of MONITOR and MWAIT, these two instructions are available to ring 0 and condition- 
ally available at ring level greater than 0. Before an application attempts to use the MONITOR and MWAIT instruc- 
tions, the application should use the following steps: 


1. Check that the processor supports MONITOR and MWAIT. If CPUID.01H:ECX.MONITOR[bit 3] = 1, MONITOR 
and MWAIT are available at ring 0. 


2. Query the smallest and largest line size that MONITOR uses. Use CPUID.05H:EAX.smallest[bits 
15:0];EBX.largest[bits15:0]. Values are returned in bytes in EAX and EBX. 


3. Ensure the memory address range(s) that will be supplied to MONITOR meets memory type requirements. 
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MONITOR and MWAIT are targeted for system software that supports efficient thread synchronization, See Chapter 
13 in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A for details. 


12.4.3. Enable FTZ and DAZ for SIMD Floating-Point Computation 


Enabling the FTZ and DAZ flags in the MXCSR register is likely to accelerate SIMD floating-point computation where 
strict compliance to the IEEE standard 754-1985 is not required. The FTZ flag is available to Intel 64 and IA-32 
processors that support the SSE; DAZ is available to Intel 64 processors and to most IA-32 processors that support 
SSE/SSE2/SSE3. 


Software can detect the presence of DAZ, modify the MXCSR register, and save and restore state information by 
following the techniques discussed in Section 11.6.3 through Section 11.6.6. 


12.4.4 Programming SSE3 with SSE/SSE2 Extensions 


SIMD instructions in SSE3 extensions are intended to complement the use of SSE/SSE2 in programming SIMD 
applications. Application software that intends to use SSE3 instructions should also check for the availability of 
SSE/SSE2 instructions. 


The FISTTP instruction in SSE3 is intended to accelerate x87 style programming where performance is limited by 
frequent floating-point conversion to integers; this happens when the x87 FPU control word is modified frequently. 
Use of FISTTP can eliminate the need to access the x87 FPU control word. 


12.5 OVERVIEW OF SSSE3 INSTRUCTIONS 

SSSE3 provides 32 instructions to accelerate a variety of multimedia and signal processing applications employing 
SIMD integer data. See: 

® Section 12.6, “SSSE3 Instructions,” provides an introduction to individual SSSE3 instructions. 


° Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A & 2B, provide detailed 
information on individual instructions. 


¢ Chapter 13, “System Programming for Instruction Set Extensions and Processor Extended States,” in the 
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, gives guidelines for integrating 
SSE/SSE2/SSE3/SSSE3 extensions into an operating-system environment. 


12.6 SSSE3 INSTRUCTIONS 


SSSE3 instructions include: 

° Twelve instructions that perform horizontal addition or subtraction operations. 

¢ Six instructions that evaluate the absolute values. 

¢* Two instructions that perform multiply and add operations and speed up the evaluation of dot products. 

¢ Two instructions that accelerate packed-integer multiply operations and produce integer values with scaling. 
° Two instructions that perform a byte-wise, in-place shuffle according to the second shuffle control operand. 


¢ Six instructions that negate packed integers in the destination operand if the signs of the corresponding 
element in the source operand is less than zero. 


¢ Two instructions that align data from the composite of two operands. 


The operands of these instructions are packed integers of byte, word, or double word sizes. The operands are 
stored as 64 or 128 bit data in MMX registers, XMM registers, or memory. 


The instructions are discussed in more detail in the following paragraphs. 
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12.6.1 Horizontal Addition/Subtraction 


In analogy to the packed, floating-point horizontal add and subtract instructions in SSE3, SSSE3 offers similar 
capabilities on packed integer data. Data elements of signed words, doublewords are supported. Saturated version 
for horizontal add and subtract on signed words are also supported. The horizontal data movement of PHADD is 
shown in Figure 12-3. 


—¢ 


Y2+Y3 | YO+Y1 | X2 + X3 | XO + X1 


Figure 12-3. Horizontal Data Movement in PHADDD 


There are six horizontal add instructions (represented by three mnemonics); three operate on 128-bit operands 
and three operate on 64-bit operands. The width of each data element is either 16 bits or 32 bits. The mnemonics 
are listed below. 


¢ PHADDW adds two adjacent, signed 16-bit integers horizontally from the source and destination operands and 
packs the signed 16-bit results to the destination operand. 


¢ PHADDSW adds two adjacent, signed 16-bit integers horizontally from the source and destination operands 
and packs the signed, saturated 16-bit results to the destination operand. 


¢ PHADDD adds two adjacent, signed 32-bit integers horizontally from the source and destination operands and 
packs the signed 32-bit results to the destination operand. 


There are six horizontal subtract instructions (represented by three mnemonics); three operate on 128-bit oper- 
ands and three operate on 64-bit operands. The width of each data element is either 16 bits or 32 bits. These are 
listed below. 


¢ PHSUBW performs horizontal subtraction on each adjacent pair of 16-bit signed integers by subtracting the 
most significant word from the least significant word of each pair in the source and destination operands. The 
signed 16-bit results are packed and written to the destination operand. 


¢ PHSUBSW performs horizontal subtraction on each adjacent pair of 16-bit signed integers by subtracting the 
most significant word from the least significant word of each pair in the source and destination operands. The 
signed, saturated 16-bit results are packed and written to the destination operand. 


¢ PHSUBD performs horizontal subtraction on each adjacent pair of 32-bit signed integers by subtracting the 
most significant doubleword from the least significant double word of each pair in the source and destination 
operands. The signed 32-bit results are packed and written to the destination operand. 


12.6.2 Packed Absolute Values 


There are six packed-absolute-value instructions (represented by three mnemonics). Three operate on 128-bit 
operands and three operate on 64-bit operands. The widths of data elements are 8 bits, 16 bits or 32 bits. The 
absolute value of each data element of the source operand is stored as an UNSIGNED result in the destination 

operand. 


¢ PABSB computes the absolute value of each signed byte data element. 
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¢ PABSW computes the absolute value of each signed 16-bit data element. 
¢ PABSD computes the absolute value of each signed 32-bit data element. 


12.6.3. Multiply and Add Packed Signed and Unsigned Bytes 


There are two multiply-and-add-packed-signed-unsigned-byte instructions (represented by one mnemonic). One 
operates on 128-bit operands and the other operates on 64-bit operands. Multiplications are performed on each 
vertical pair of data elements. The data elements in the source operand are signed byte values, the input data 
elements of the destination operand are unsigned byte values. 


¢ PMADDUBSW multiplies each unsigned byte value with the corresponding signed byte value to produce an 
intermediate, 16-bit signed integer. Each adjacent pair of 16-bit signed values are added horizontally. The 
signed, saturated 16-bit results are packed to the destination operand. 


12.6.4 Packed Multiply High with Round and Scale 


There are two packed-multiply-high-with-round-and-scale instructions (represented by one mnemonic). One oper- 
ates on 128-bit operands and the other operates on 64-bit operands. 


¢ PMULHRSW multiplies vertically each signed 16-bit integer from the destination operand with the corre- 
sponding signed 16-bit integer of the source operand, producing intermediate, signed 32-bit integers. Each 
intermediate 32-bit integer is truncated to the 18 most significant bits. Rounding is always performed by adding 
1 to the least significant bit of the 18-bit intermediate result. The final result is obtained by selecting the 16 bits 
immediately to the right of the most significant bit of each 18-bit intermediate result and packed to the 
destination operand. 


12.6.5 Packed Shuffle Bytes 


There are two packed-shuffle-bytes instructions (represented by one mnemonic). One operates on 128-bit oper- 
ands and the other operates on 64-bit operands. The shuffle operations are performed bytewise on the destination 
operand using the source operand as a control mask. 


¢ PSHUFB permutes each byte in place, according to a shuffle control mask. The least significant three or four bits 
of each shuffle control byte of the control mask form the shuffle index. The shuffle mask is unaffected. If the 
most significant bit (bit 7) of a shuffle control byte is set, the constant zero is written in the result byte. 


12.6.6 Packed Sign 


There are six packed-sign instructions (represented by three mnemonics). Three operate on 128-bit operands and 
three operate on 64-bit operands. The widths of each data element for these instructions are 8 bit, 16 bit or 32 bit 
signed integers. 


¢ PSIGNB/W/D negates each signed integer element of the destination operand if the sign of the corresponding 
data element in the source operand is less than zero. 


12.6.7. Packed Align Right 


There are two packed-align-right instructions (represented by one mnemonic). One operates on 128-bit operands 
and the other operates on 64-bit operands. These instructions concatenate the destination and source operand into 
a composite, and extract the result from the composite according to an immediate constant. 


¢ PALIGNR’s source operand is appended after the destination operand forming an intermediate value of twice 
the width of an operand. The result is extracted from the intermediate value into the destination operand by 
selecting the 128-bit or 64-bit value that are right-aligned to the byte offset specified by the immediate value. 
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12.7. WRITING APPLICATIONS WITH SSSE3 EXTENSIONS 


The following sections give guidelines for writing application programs and operating-system code that use SSSE3 
instructions. 


12.7.1 Guidelines for Using SSSE3 Extensions 


The following guidelines describe how to maximize the benefits of using SSSE3 extensions: 
° Check that the processor supports SSSE3 extensions. 


¢ Ensure that your operating system supports SSE/SSE2/SSE3/SSSE3 extensions. (Operating system support 
for the SSE extensions implies sufficient support for SSE2, SSE3, and SSSE3.) 


¢ Employ the optimization and scheduling techniques described in the Intel® 64 and IA-32 Architectures Optimi- 
zation Reference Manual (see Section 1.4, “Related Literature”). 


12.7.2 Checking for SSSE3 Support 

Before an application attempts to use the SSSE3 extensions, the application should follow the steps illustrated in 
Section 11.6.2, “Checking for SSE/SSE2 Support.” Next, use the additional step provided below: 

° Check that the processor supports SSSE3 (if CPUID.01H:ECX.SSSE3[bit 9] = 1). 


12.8 SSE3/SSSE3 AND SSE4 EXCEPTIONS 


SSE3, SSSE3, and SSE4 instructions can generate the same type of memory-access and non-numeric exceptions 
as other Intel 64 or IA-32 instructions. Existing exception handlers generally handle these exceptions without code 
modification. 


FISTTP can generate floating-point exceptions. Some SSE3 instructions can also generate SIMD floating-point 
exceptions. 


SSE3 additions and changes are noted in the following sections. See also: Section 11.5, “SSE, SSE2, and SSE3 
Exceptions”. 


12.8.1 Device Not Available (DNA) Exceptions 


SSE3, SSSE3, and SSE4 will cause a DNA Exception (#NM) if the processor attempts to execute an SSE3 instruc- 
tion while CRO.TS[bit 3] = 1. If CPUID.OLH:ECX.SSE3[bit 0] = 0, execution of an SSE3 extension will cause an 
invalid opcode fault regardless of the state of CRO.TS[bit 3]. 


Similarly, an attempt to execute an SSSE3 instruction on a processor that reports CPUID.01H:ECX.SSSE3[bit 9] = 
0 will cause an invalid opcode fault regardless of the state of CRO.TS[bit 3]. An attempt to execute an SSE4.1 
instruction on a processor that reports CPUID.O1H:ECX.SSE4_1[bit 19] = 0 will cause an invalid opcode fault 
regardless of the state of CRO.TS[bit 3]. 


An attempt to execute PCMPGTQ or any one of the four string processing instructions in SSE4.2 on a processor that 
reports CPUID.O1H:ECX.SSSE3[bit 20] = 0 will cause an invalid opcode fault regardless of the state of 
CRO.TS[bit 3]. CRC32 and POPCNT do not cause #NM. 


12.8.2 Numeric Error flag and IGNNE# 


Most SSE3 instructions ignore CRO.NE[bit 5] (treats it as if it were always set) and the IGNNE# pin. With one 
exception, all use the exception 19 (#XM) software exception for error reporting. The exception is FISTTP; it 
behaves like other x87-FP instructions. 


SSSE3 instructions ignore CRO.NE[bit 5] (treats it as if it were always set) and the IGNNE# pin. 
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SSSE3 instructions do not cause floating-point errors. Floating-point numeric errors for SSE4.1 are described in 
Section 12.8.4. SSE4.2 instructions do not cause floating-point errors. 


12.8.3 Emulation 


CRO.EM is used by some software to emulate x87 floating-point instructions, CRO.EM[bit 2] cannot be used for 
emulation of SSE, SSE2, SSE3, SSSE3, and SSE4. If an SSE3, SSSE3, and SSE4 instruction executes with 
CRO.EM[bit 2] set, an invalid opcode exception (INT 6) is generated instead of a device not available exception (INT 
7). 


12.8.4 IEEE 754 Compliance of SSE4.1 Floating-Point Instructions 


The six SSE4.1 instructions that perform floating-point arithmetic are: 


* DPPS 
* DPPD 
* ROUNDPS 
* ROUNDPD 
* ROUNDSS 
* ROUNDSD 


Dot Product operations are not specified in IEEE-754. When neither FTZ nor DAZ are enabled, the dot product 
instructions resemble sequences of IEEE-754 multiplies and adds (with rounding at each stage), except that the 
treatment of input NaN’s is implementation specific (there will be at least one NaN in the output). The input select 
fields (bits imm8[4:7]) force input elements to +0.0f prior to the first multiply and will suppress input exceptions 
that would otherwise have been be generated. 


As a convenience to the exception handler, any exceptions signaled from DPPS or DPPD leave the destination 
unmodified. 


Round operations signal invalid and precision only. 


Table 12-1. SIMD numeric exceptions signaled by SSE4.1 


DPPS DPPD ROUNDPS ROUNDPD 
ROUNDSS ROUNDSD 

Overflow X X 
Underflow X X 
Invalid X X X @) X @) 
Inexact Precision X Xx X (2) X 2) 
Denormal X X 
NOTE: 


1. Invalid is signaled only if Src = SNaN. 
2. Precision is ignored (regardless of the MXCSR precision mask) if if imm8[3] = ‘1’. 


The other SSE4.1 instructions with floating-point arguments (BLENDPS, BLENDPD, BLENDVPS, BLENDVPD, 
INSERTPS, EXTRACTPS) do not signal any SIMD numeric exceptions. 


12.9 SSE4 OVERVIEW 


SSE4 comprises two sets of extensions: SSE4.1 and SSE4.2. SSE4.1 is targeted to improve the performance of 
media, imaging, and 3D workloads. SSE4.1 adds instructions that improve compiler vectorization and significantly 
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increase support for packed dword computation. The technology also provides a hint that can improve memory 
throughput when reading from uncacheable WC memory type. 


The 47 SSE4.1 instructions include: 

® Two instructions perform packed dword multiplies. 

¢ Two instructions perform floating-point dot products with input/output selects. 

* One instruction performs a load with a streaming hint. 

¢ Six instructions simplify packed blending. 

¢ Eight instructions expand support for packed integer MIN/MAX. 

¢ Four instructions support floating-point round with selectable rounding mode and precision exception override. 
¢ Seven instructions improve data insertion and extractions from XMM registers 

¢ Twelve instructions improve packed integer format conversions (sign and zero extensions). 

* One instruction improves SAD (sum absolute difference) generation for small block sizes. 

* One instruction aids horizontal searching operations. 

¢* One instruction improves masked comparisons. 

® One instruction adds qword packed equality comparisons. 

* One instruction adds dword packing with unsigned saturation. 

The SSE4.2 instructions operating on XMM registers improve performance in the following areas: 


¢ String and text processing that can take advantage of single-instruction multiple-data programming 
techniques. 


¢ ASIMD integer instruction that enhances the capability of the 128-bit integer SIMD capability in SSE4.1. 


12.10 SSE4.1 INSTRUCTION SET 


12.10.1 Dword Multiply Instructions 


SSE4.1 adds two dword multiply instructions that aid vectorization. They allow four simultaneous 32 bit by 32 bit 
multiplies. PMULLD returns a low 32-bits of the result and PMULDQ returns a 64-bit signed result. These represent 
the most common integer multiply operation. See Table 12-2. 


Table 12-2. Enhanced 32-bit SIMD Multiply Supported by SSE4.1 


32 bit Integer Operation 
unsigned x unsigned signed x signed 
e Low 32-bit (not available) PMULLD 
FA High 32-bit (not available) (not available) 
a 64-bit PMULUDQ* PMULDQ 
NOTE: 


* Available prior to SSE4.1. 


12.10.2 Floating-Point Dot Product Instructions 


SSE4.1 adds two instructions for double-precision (for up to 2 elements; DPPD) and single-precision dot products 
(for up to 4 elements; DPPS). 


These dot-product instructions include source select and destination broadcast which generally improves the flex- 
ibility. For example, a single DPPS instruction can be used for a 2, 3, or 4 element dot product. 
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12.10.3 Streaming Load Hint Instruction 


Historically, CPU read accesses of WC memory type regions have significantly lower throughput than accesses to 
cacheable memory. 


The streaming load instruction in SSE4.1, MOVNTDQA, provides a non-temporal hint that can cause adjacent 16- 
byte items within an aligned 64-byte region of WC memory type (a streaming line) to be fetched and held in a small 
set of temporary buffers (“streaming load buffers”). Subsequent streaming loads to other aligned 16-byte items in 
the same streaming line may be satisfied from the streaming load buffer and can improve throughput. 


Programmers are advised to use the following practices to improve the efficiency of MOVNTDQA streaming loads 
from WC memory: 


Streaming loads must be 16-byte aligned. 


Temporally group streaming loads of the same streaming cache line for effective use of the small number of 
streaming load buffers. If loads to the same streaming line are excessively spaced apart, it may cause the 
streaming line to be re-fetched from memory. 


Temporally group streaming loads from at most a few streaming lines together. The number of streaming load 
buffers is small; grouping a modest number of streams will avoid running out of streaming load buffers and the 
resultant re-fetching of streaming lines from memory. 


Avoid writing to a streaming line until all 16-byte-aligned reads from the streaming line have occurred. Reading 
a 16-byte item from a streaming line that has been written, may cause the streaming line to be re-fetched. 


Avoid reading a given 16-byte item within a streaming line more than once; repeated loads of a particular 16- 
byte item are likely to cause the streaming line to be re-fetched. 


The streaming load buffers, reflecting the WC memory type characteristics, are not required to be snooped by 
operations from other agents. Software should not rely upon such coherency actions to provide any data 
coherency with respect to other logical processors or bus agents. Rather, software must ensure the consistency 
of WC memory accesses between producers and consumers. 


Streaming loads may be weakly ordered and may appear to software to execute out of order with respect to 
other memory operations. Software must explicitly use MFENCE if it needs to preserve order among streaming 
loads or between streaming loads and other memory operations. 


Streaming loads must not be used to reference memory addresses that are mapped to I/O devices having side 
effects or when reads to these devices are destructive. This is because MOVNTDQA is speculative in nature. 


Example 12-1 provides a sketch of the basic assembly sequences that illustrate the principles of using MOVNTDQA 
in a situation with a producer-consumer accessing a WC memory region. 
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Example 12-1. Sketch of MOVNTDQA Usage of a Consumer and a PCI Producer 


// PO: producer is a PCI device writing into the WC space 
# the PCI device updates status through a UC flag, “u_dev_status” . 
# the protocol for “u_dev_status” : 0: produce; 1: consume; 2: all done 


mov eax, $O 
mov [u_dev_status], eax 
producerStart: 
mov eax, [u_dev_status] # poll status flag to see if consumer is requestion data 
cmp eax, $O # 
jne done # | no longer need to produce 


commence PCI writes to WC region.. 


mov eax, $1 # producer ready to notify the consumer via status flag 
mov [u_dev_status], eax 
# now wait for consumer to signal its status 


spinloop: 
cmp [u_dev_status],$1  # did | get a signal from the consumer ? 
jne producerStart # yes | did 
jmp spinloop # check again 

done: 


// producer is finished at this point 


// P1: consumer check PCI status flag to consume WC data 
mov eax, SO # request to the producer 
mov [u_dev_status], eax 


consumerStart: 
mov; eax, [U_dev_status] # reads the value of the PCI status 
cmp eax, $1 # has producer written 
jne consumerStart # tight loop; make it more efficient with pause, etc. 


mfence # producer finished device writes to WC, ensure WC region is coherent 
ntread: 

movntdga xmm0O, [addr] 

movntdga xmm1, [addr + 16] 

movntdga xmm2, [addr + 32] 

movntdga xmm3, [addr + 48] 

.. #do any more NT reads as needed 

mfence # ensure PCI device reads the correct value of [u_dev_status] 
# now decide whether we are done or we need the producer to produce more data 
# if we are done write a 2 into the variable, otherwise write a 0 into the variable 

mov eax, $0/S$2 # end or continue producing 

mov [u_dev_status], eax 
# if | want to consume again | will jump back to consumerStart after storing a O into eax 
# otherwise | am done 
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12.10.4 Packed Blending Instructions 
SSE4.1 adds 6 instructions used for blending (BLENDPS, BLENDPD, BLENDVPS, BLENDVPD, PBLENDVB, 


PBLENDW). 


Blending conditionally copies a data element in a source operand to the same element in the destination. SSE4.1 
instructions improve blending operations for most field sizes. A single new SSE4.1 instruction can generally replace 
a sequence of 2 to 4 operations using previous architectures. 


The variable blend instructions (BLENDVPS, BLENDVPD, PBLENDW) introduce the use of control bits stored in an 


implicit XMM register (XMMO). The most significant bit in each field (the sign bit, for 2’s complement integer or 
floating-point) is used as a selector. See Table 12-3. 


Table 12-3. Blend Field Size and Control Modes Supported by SSE4.1 
Packed Packed Packed Packed Packed 

Instructions Double FP Single FP | QWord DWord Word Packed Byte | Blend Control 
BLENDPS X Imms 
BLENDPD X Imms 
BLENDVPS X xX) XMMO 
BLENDVPD X Xx) XMMO 
PBLENDVB (2) (2) (2) x XMMO 
PBLENDW xX x Xx Imms 

NOTE: 


1. Use of floating-point SIMD instructions on integer data types may incur performance penalties. 


2. Byte variable blend can be used for larger sized fields by reformatting (or shuffling) the blend control. 


12.10.5 Packed Integer MIN/MAX Instructions 


SSE4.1 adds 8 packed integer MIN and MAX instructions (PMINUW, PMINUD, PMINSB, PMINSD; PMAXUW, 


PMAXUD, PMAXSB, PMAXSD). 


Four 32-bit integer packed MIN and MAX instructions operate on unsigned and signed dwords. Two instructions 
operate on signed bytes. Two instructions operate on unsigned words. See Table 12-4. 


Table 12-4. Enhanced SIMD Integer MIN/MAX Instructions Supported by SSE4.1 


Integer Width 
Byte Word DWord 
Integer PMINUB* PMINUW PMINUD 
Format Unsigned PMAXUB* PMAXUW PMAXUD 
PMINSB PMINSW* PMINSD 
Signed PMAXSB PMAXSW* PMAXSD 
NOTE: 


* Available prior to SSE4.1. 


12.10.6 Floating-Point Round Instructions with Selectable Rounding Mode 

High level languages and libraries often expose rounding operations having a variety of numeric rounding and 
exception behaviors. Using SSE/SSE2/SSE3 instructions to mitigate the rounding-mode-related problem is some- 
times not straight forward. 

SSE4.1 introduces four rounding instructions (ROUNDPS, ROUNDPD, ROUNDSS, ROUNDSD) that cover scalar and 


packed single- and double-precision floating-point operands. The rounding mode can be selected using an imme- 
diate from one of the IEEE-754 modes (Nearest, -Inf, +Inf, and Truncate) without changing the current rounding 
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mode; or the instruction can be forced to use the current rounding mode. Another bit in the immediate is used to 
suppress inexact precision exceptions. 


Rounding instructions in SSE4.1 generally permit single-instruction solutions to C99 functions ceil(), floor(), 
trunc(), rint(), nearbyint(). These instructions simplify the implementations of half-way-away-from-zero rounding 
modes as used by C99 round() and F90’s nint(). 


12.10.7 Insertion and Extractions from XMM Registers 


SSE4.1 adds 7 instructions (corresponding to 9 assembly instruction mnemonics) that simplify data insertion and 
extraction between general-purpose register (GPR) and XMM registers (EXTRACTPS, INSERTPS, PINSRB, PINSRD, 
PINSRQ, PEXTRB, PEXTRW, PEXTRD, and PEXTRQ). When accessing memory, no alignment is required for any of 
these instructions (unless alignment checking is enabled). 


EXTRACTPS extracts a single-precision floating-point value from any dword offset in an XMM register and stores 
the result to memory or a general-purpose register. INSERTPS inserts a single floating-point value from either a 
32-bit memory location or from specified element in an XMM register to a selected element in the destination XMM 
register. In addition, INSERTPS allows the insertion of +0.0f into any destination elements using a mask. 


PINSRB, PINSRD, and PINSRQ insert byte, dword, or qword integer values from a register or memory into an XMM 
register. Insertion of integer word values were already supported by SSE2 (PINSRW). 


PEXTRB, PEXTRW, PEXTRD, and PEXTRQ extract byte, word, dword, and qword from an XMM register and insert the 
values into a general-purpose register or memory. 


12.10.8 Packed Integer Format Conversions 


A common type of operation on packed integers is the conversion by zero- or sign-extension of packed integers 
into wider data types. SSE4.1 adds 12 instructions that convert from a smaller packed integer type to a larger 
integer type (PMOVSXBW, PMOVZXBW, PMOVSXBD, PMOVZXBD, PMOVSXWD, PMOVZXWD, PMOVSXBQ, 
PMOVZXBQ, PMOVSXWQ, PMOVZXWQ, PMOVSXDQ, PMOVZXDQ). 


The source operand is from either an XMM register or memory; the destination is an XMM register. See Table 12-5. 


When accessing memory, no alignment is required for any of the instructions unless alignment checking is enabled. 
In which case, all conversions must be aligned to the width of the memory reference. The number of elements 
converted (and width of memory reference) is illustrated in Table 12-6. The alignment requirement is shown in 
parenthesis. 


Table 12-5. New SIMD Integer conversions supported by SSE4.1 


Source Type 
Byte Word Dword 
Signed Word PMOVSXBW 
Unsigned Word PMOVZXBW 
Cc 
2 Signed Dword PMOVSXBD PMOVSXWD 
2 Unsigned Dword PMOVZXBD PMOVZXWD 
% a Signed Qword PMOVSXBQ PMOVSXWQ PMOVSXDQ 
OF Unsigned Qword PMOVZXBQ PMOVZXWQ PMOVZXDQ 
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Table 12-6. New SIMD Integer Conversions Supported by SSE4.1 


Source Type 
Byte Word Dword 
= Word 8 (64 bits) 
2 Dword 4 (32 bits) 4 (64 bits) 
5 oy Qword 2 (16 bits) 2 (32 bits) 2 (64 bits) 
ar 


12.10.9 Improved Sums of Absolute Differences (SAD) for 4-Byte Blocks 


SSE4.1 adds an instruction (MPSADBW) that performs eight 4-byte wide SAD operations per instruction to produce 
eight results. Compared to PSPADBW, MPSADBW operates on smaller chunks (4-byte instead of 8-byte chunks); this 
makes the instruction better suited to video coding standards such as VC.1 and H.264. MPSADBW performs four 
times the number of absolute difference operations than that of PSADBW (per instruction). This can improve 
performance for dense motion searches. 

MPSADBW uses a 4-byte wide field from a source operand; the offset of the 4-byte field within the 128-bit source 
operand is specified by two immediate control bits. MPSADBW produces eight 16-bit SAD results. Each 16-bit SAD 
result is formed from overlapping pairs of 4 bytes in the destination with the 4-byte field from the source operand. 
MPSADBW uses eleven consecutive bytes in the destination operand, its offset is specified by a control bit in the 
immediate byte (i.e. the offset can be from byte O or from byte 4). Figure 12-4 illustrates the operation of 
MPSADBW. MPSADBW can simplify coding of dense motion estimation by providing source and destination offset 
control, higher throughput of SAD operations, and the smaller chunk size. 


Imm[1:0]*32 
127 96 64 


Source ‘< 
(Ae. Dif) Imm[2]*32 


Destination 
127 ae oe / | 16 0 


Figure 12-4. MPSADBW Operation 


12.10.10 Horizontal Search 


SSE4.1 adds a search instruction (PHMINPOSUW) that finds the value and location of the minimum unsigned word 
from one of 8 horizontally packed unsigned words. The resulting value and location (offset within the source) are 
packed into the low dword of the destination XMM register. 

Rapid search is often a significant component of motion estimation. MPSADBW and PHMINPOSUW can be used 
together to improve video encode. 
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12.10.11 Packed Test 


The packed test instruction PTEST is similar to a 128-bit equivalent to the legacy instruction TEST. With PTEST, the 
source argument is typically used like a bit mask. 


PTEST performs a logical AND between the destination with this mask and sets the ZF flag if the result is zero. The 
CF flag (zero for TEST) is set if the inverted mask AND’d with the destination is all zero. Because the destination is 
not modified, PTEST simplifies branching operations (such as branching on signs of packed floating-point numbers, 
or branching on zero fields). 


12.10.12 Packed Qword Equality Comparisons 


SSE4.1 adds a 128-bit packed qword equality test. The new instruction (PCMPEQQ) is identical to PCMPEQD, but 
has qword granularity. 


12.10.13 Dword Packing With Unsigned Saturation 


SSE4.1 adds a new instruction PACKUSDW to complete the set of small integer pack instructions in the family of 
SIMD instruction extensions. PACKUSDW packs dword to word with unsigned saturation. See Table 12-7 for the 
complete set of packing instructions for small integers. 


Table 12-7. Enhanced SIMD Pack support by SSE4.1 


Pack Type 

DWord -> word Word -> Byte 
2 Unsigned PACKUSDW (new!) PACKUSWB 
2 Signed PACKSSDW PACKSSWB 
28 
om 
ne 


12.11 SSE4.2 INSTRUCTION SET 


Five of the seven SSE4.2 instructions can use an XMM register as a source or destination. These include four 
text/string processing instructions and one packed quadword compare SIMD instruction. Programming these five 
SSE4.2 instructions is similar to programming 128-bit Integer SIMD in SSE2/SSSE3. SSE4.2 does not provide any 
64-bit integer SIMD instructions. 


12.11.1 String and Text Processing Instructions 


String and text processing instructions in SSE4.2 allocates 4 opcodes to provide a rich set of string and text 
processing capabilities that traditionally required many more opcodes. These 4 instructions use XMM registers to 
process string or text elements of up to 128-bits (16 bytes or 8 words). Each instruction uses an immediate byte 
to support a rich set of programmable controls. A string-processing SSE4.2 instruction returns the result of 
processing each pair of string elements using either an index or a mask. 

The capabilities of the string/text processing instructions include: 

¢* Handling string/text fragments consisting of bytes or words, either signed or unsigned 


¢ Support for partial string or fragments less than 16 bytes in length, using either explicit length or implicit null- 
termination 


¢ Four types of string compare operations on word/byte elements 
¢ Up to 256 compare operations performed in a single instruction on all string/text element pairs 
¢ Built-in aggregation of intermediate results from comparisons 
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¢ Programmable control of processing on intermediate results 

¢ Programmable control of output formats in terms of an index or mask 

¢ Bi-directional support for the index format 

¢ Support for two mask formats: bit or natural element width 

¢ Not requiring 16-byte alignment for memory operand 

The four SSE4.2 instructions that process text/string fragments are: 

¢ PCMPESTRI — Packed compare explicit-length strings, return index in ECX/RCX 
¢ PCMPESTRM — Packed compare explicit-length strings, return mask in XMMO 

¢ PCMPISTRI — Packed compare implicit-length strings, return index in ECX/RCX 
¢ PCMPISTRM — Packed compare implicit-length strings, return mask in XMMO 


All four require the use of an immediate byte to control operation. The two source operands can be XMM registers 
or a combination of XMM register and memory address. The immediate byte provides programmable control with 
the following attributes: 


¢ Input data format 

* Compare operation mode 

¢ Intermediate result processing 
* Output selection 


Depending on the output format associated with the instruction, the text/string processing instructions implicitly 
uses either a general-purpose register (ECX/RCX) or an XMM register (XMMO) to return the final result. 


Two of the four text-string processing instructions specify string length explicitly. They use two general-purpose 
registers (EDX, EAX) to specify the number of valid data elements (either word or byte) in the source operands. The 
other two instructions specify valid string elements using null termination. A data element is considered valid only 
if it has a lower index than the least significant null data element. 


12.11.1.1 Memory Operand Alignment 


The text and string processing instructions in SSE4.2 do not perform alignment checking on memory operands. 
This is different from most other 128-bit SIMD instructions accessing the XMM registers. The absence of an align- 
ment check for these four instructions does not imply any modification to the existing definitions of other instruc- 
tions. 


12.11.2 Packed Comparison SIMD Integer Instruction 


SSE4.2 also provides a 128-bit integer SIMD instruction PCMPGTQ that performs logical compare of greater-than 
on packed integer quadwords. 


12.12 WRITING APPLICATIONS WITH SSE4 EXTENSIONS 


12.12.1 Guidelines for Using SSE4 Extensions 


The following guidelines describe how to maximize the benefits of using SSE4 extensions: 
® Check that the processor supports SSE4 extensions. 


¢ Ensure that your operating system supports SSE/SSE2/SSE3/SSSE3 extensions. (Operating system support 
for the SSE extensions implies sufficient support for SSE2, SSE3, SSSE3, and SSE4.) 


¢ Employ the optimization and scheduling techniques described in the Inte/® 64 and IA-32 Architectures Optimi- 
zation Reference Manual (see Section 1.4, “Related Literature”). 
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12.12.2 Checking for SSE4.1 Support 


Before an application attempts to use SSE4.1 instructions, the application should follow the steps illustrated in 
Section 11.6.2, “Checking for SSE/SSE2 Support.” Next, use the additional step provided below: 


Check that the processor supports SSE4.1 (if CPUID.OLH:ECX.SSE4_i[bit 19] = 1), SSE3 (if 
CPUID.01H:ECX.SSE3[bit 0] = 1), and SSSE3 (if CPUID.01H:ECX.SSSE3[bit 9] = 1). 


12.12.3 Checking for SSE4.2 Support 


Before an application attempts to use the following SSE4.2 instructions: PCMPESTRI/PCMPESTRM/PCMP- 
ISTRI/PCMPISTRM, PCMPGTQ;the application should follow the steps illustrated in Section 11.6.2, “Checking for 
SSE/SSE2 Support.” Next, use the additional step provided below: 


Check that the processor supports SSE4.2 (if CPUID.OLH:ECX.SSE4_2[bit 20] = 1), SSE4.1 (if 
CPUID.01H:ECX.SSE4_1[bit 19] = 1), and SSSE3 (if CPUID.O1H:ECX.SSSE3[bit 9] = 1). 


Before an application attempts to use the CRC32 instruction, it must check that the processor supports SSE4.2 (if 
CPUID.01H:ECX.SSE4_2[bit 20] = 1). 


Before an application attempts to use the POPCNT instruction, it must check that the processor supports SSE4.2 (if 
CPUID.01H:ECX.SSE4_2[bit 20] = 1) and POPCNT (if CPUID.01H:ECX.POPCNT[bit 23] = 1). 


12.13 AESNI OVERVIEW 


The AESNI extension provides six instructions to accelerate symmetric block encryption/decryption of 128-bit data 
blocks using the Advanced Encryption Standard (AES) specified by the NIST publication FIPS 197. Specifically, two 
instructions (AESENC, AESENCLAST) target the AES encryption rounds, two instructions (AESDEC, AESDECLAST) 
target AES decryption rounds using the Equivalent Inverse Cipher. One instruction (AESIMC) targets the Inverse 
MixColumn transformation primitive and one instruction (AESKEYGEN) targets generation of round keys from the 
cipher key for the AES encryption/decryption rounds. 


AES supports encryption/decryption using cipher key lengths of 128, 192, and 256 bits by processing the data 
block in 10, 12, 14 rounds of predefined transformations. Figure 12-5 depicts the cryptographic processing of a 
block of 128-bit plain text into cipher text. 


RK(0) RK(1) RK(n-1) 


> Rounds 2.. n-2 ul 


Round 1 Last 
Plain text AES State AES State AES State ROW"4 Cipher text 
AES-128: n= 10 
AES-192: n= 12 
AES-256: n= 14 


Figure 12-5. AES State Flow 


The predefined AES transformation primitives are described in the next few sections, they are also referenced in 
the operation flow of instruction reference page of these instructions. 


12.13.1  Little-Endian Architecture and Big-Endian Specification (FIPS 197) 


FIPS 197 document defines the Advanced Encryption Standard (AES) and includes a set of test vectors for testing 
all of the steps in the algorithm, and can be used for testing and debugging. 
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The following observation is important for using the AES instructions offered in Intel 64 Architecture: FIPS 197 text 
convention is to write hex strings with the low-memory byte on the left and the high-memory byte on the right. 
Intel’s convention is the reverse. It is similar to the difference between Big Endian and Little Endian notations. 


In other words, a 128 bits vector in the FIPS document, when read from left to right, is encoded as [7:0, 15:8, 
23:16, 31:24, ...127:120]. Note that inside the byte, the encoding is [7:0], so the first bit from the left is the most 
significant bit. In practice, the test vectors are written in hexadecimal notation, where pairs of hexadecimal digits 
define the different bytes. To translate the FIPS 197 notation to an Intel 64 architecture compatible (“Little Endian”) 
format, each test vector needs to be byte-reflected to [127:120,... 31:24, 23:16, 15:8, 7:0]. 


Example A: 
FIPS Test vector: 000102030405060708090a0b0cOd0e0fH 
Intel AES Hardware: O0fO0e0d0c0b0a09080706050403020100H 


It should be pointed out that the only thing at issue is a textual convention, and programmers do not need to 
perform byte-reversal in their code, when using the AES instructions. 


12.13.1.1 AES Data Structure in Intel 64 Architecture 


The AES instructions that are defined in this document operate on one or on two 128 bits source operands: State 
and Round Key. From the architectural point of view, the state is input in an xmm register and the Round key is 
input either in an xmm register or a 128-bit memory location. 


In AES algorithm, the state (128 bits) can be viewed as 4 32-bit doublewords (“Word”s in AES terminology): X3, 
X2, X1, X0. 


The state may also be viewed as a set of 16 bytes. The 16 bytes can also be viewed as a 4x4 matrix of bytes where 
S(i, j) with i, j] = 0, 1, 2, 3 compose the 32-bit “word”s as follows: 


X0 = S (3, 0) S (2, 0) S (1, 0) S (0, 0) 
X1 =S(3,1)S(2,1)S (1, 1) S (0, 1) 
X2 =S (3, 2) S (2, 2) S (1, 2) S (0, 2) 
X3 = S (3, 3) S (2, 3) S (1, 3) S (0, 3) 
The following tables, Table 12-8 through Table 12-11, illustrate various representations of a 128-bit state. 


Table 12-8. Byte and 32-bit Word Representation of a 128-bit State 
Byte # 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


Bit Position | 127- | 119- | 111- | 103- | 95- | 87- | 79- | 71- | 63- | 55- | 47- | 39- | 31- | 23- | 15- | 7- 
120 |112 |103 | 96 88 |80 |72 |64 |56 |;48 |40 |32 |24 |16 |8 0 


127 - 96 95 - 64 64 - 32 31-0 


State Word X3 X2 X1 XO 


State Byte P O N M L K J | H G F E D C B A 


Table 12-9. Matrix Representation of a 128-bit State 


A E | M S(0, 0) S(0, 1) S(0, 2) S(0, 3) 

B F | N S(1, 0) S(1, 1) S(1, 2) S(1, 3) 

C G K 0) S(2, 0) S(2, 1) S(2, 2) S(2, 3) 

D H L P S(3, 0) S(3, 1) S(3, 2) S(3, 3) 
Example: 


FIPS vector: d4 bf 5d 30 e0 b4 52 ae b8 41 11 fl 1e 27 98 e5 
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This vector has the “least significant” byte d4 and the significant byte e5 (written in Big Endian format in the FIPS 
document). When it is translated to IA notations, the encoding is: 


Table 12-10. Little Endian Representation of a 128-bit State 


Byte # 15 14 | 13 12 11 10 9 8 7 6 5 4 3 2 1 


State Byte P O N M L K J | H G F E D C B A 


State Value e5 | 98 | 27 le fi] 11 41 b8 ae 52 | b4 | eO | 30 | 5d bf d4 


Table 12-11. Little Endian Representation of a 4x4 Byte Matrix 


A E | M d4 e0 b8 le 
B F J N bf b4 41 27 
C G K O 5d 52 11 98 
D H L P 30 ae fl e5 


12.13.2 AES Transformations and Functions 


The following functions and transformations are used in the algorithmic descriptions of AES instruction extensions 
AESDEC, AESDECLAST, AESENC, AESENCLAST, AESIMC, AESKEYGENASSIST. 


Note that these transformations are expressed here in a Little Endian format (and not as in the FIPS 197 docu- 
ment). 


MixColumns(): A byte-oriented 4x4 matrix transformation on the matrix representation of a 128-bit AES state. 
A FIPS-197 defined 4x4 matrix is multiplied to each 4x1 column vector of the AES state. The columns are 
considered polynomials with coefficients in the Finite Field that is used in the definition of FIPS 197, the 
operations (“multiplication” and “addition”) are in that Finite Field, and the polynomials are reduced modulo 
x"+1. 


The MixColumns() transformation defines the relationship between each byte of the result state, represented 
as S'(i, j) of a 4x4 matrix (see Section 12.13.1), as a function of input state bytes, S(i, j), as follows 


S'(0, j) := FF_MUL( 02H, S(O, j) ) XOR FF_MUL(03H, S(1, j) ) XOR S(2, j) XOR S(3, j) 
S'(1, j) := S(O, j) XOR FF_MUL( 02H, S(1, j) ) XOR FF_MUL(03H, S(2, j) ) XOR S(3, j) 
S'(2, j) := S(0, j) XOR S(1, j) XOR FF_MUL( 02H, S(2, j) ) XOR FF_MUL(03H, S(3, j) ) 
S'(3, j) := FF_MUL(03H, S(0, j) ) XOR S(1, j) XOR S(2, j) XOR FF_MUL( 02H, S(3, j) ) 


where j = 0, 1, 2, 3. FF_MUL(Byte1, Byte2) denotes the result of multiplying two elements (represented by 
Bytei and byte2) in the Finite Field representation that defines AES. The result of produced bye 
FF_MUL(Byte1, Byte2) is an element in the Finite Field (represented as a byte). A Finite Field is a field with a 
finite number of elements, and when this number can be represented as a power of 2 (2n), its elements can 
be represented as the set of 2n binary strings of length n. AES uses a finite field with n=8 (having 256 
elements). With this representation, “addition” of two elements in that field is a bit-wise XOR of their binary- 
string representation, producing another element in the field. Multiplication of two elements in that field is 
defined using an irreducible polynomial (for AES, this polynomial is m(x) = x® + x? + x? + x + 1). In this 
Finite Field representation, the bit value of bit position k of a byte represents the coefficient of a polynomial of 
order k, e.g., 1010_1101B (ADH) is represented by the polynomial (x” + x° + x? + x? + 1). The byte value 
result of multiplication of two elements is obtained by a carry-less multiplication of the two corresponding 
polynomials, followed by reduction modulo the polynomial, where the remainder is calculated using 
operations defined in the field. For example, FF_MUL(57H, 83H) = C1H, because the carry-less polynomial 
multiplication of the polynomials represented by 57H and 83H produces (x23 + x12 + x9 + x8 + x® + x? + x4 
+ x? + 1), and the remainder modulo m(x) is (x7 + x® + 1). 


RotWord(): performs a byte-wise cyclic permutation (rotate right in little-endian byte order) on a 32-bit AES 
word. 
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The output word X’[j] of RotWord(X[j]) where X[j] represent the four bytes of column j, S(i, j), in descending 
order X[j] = ( S(3, j), S(2, j), SQ, j), S(O, j) ); XT] = (S(3, j), S'(2, j), SG, §), S(O, j) ) == (S(O, j), S(3, 
j), S(2, j), SQ, j) ) 

ShiftRows(): A byte-oriented matrix transformation that processes the matrix representation of a 16-byte AES 
state by cyclically shifting the last three rows of the state by different offset to the left, see Table 12-12. 


Table 12-12. The ShiftRows Transformation 


Matrix Representation of Input State Output of ShiftRows 
A E | M A E | M 
B F J N F J N B 
C G K 0 K fe) C G 
D H L P P D H L 


SubBytes(): A byte-oriented transformation that processes the 128-bit AES state by applying a non-linear 
substitution table (S-BOX) on each byte of the state. 


The SubBytes() function defines the relationship between each byte of the result state S’(i, j) as a function of 
input state byte S(i, j), by 


Si, j) += S-Box (S(i, j)L7:4], S(i, )[3:0]) 


where S-BOX (S[7:4], S[3:0]) represents a look-up operation on a 16x16 table to return a byte value, see 
Table 12-13. 


Table 12-13. Look-up Table Associated with S-Box Transformation 


S[3:0] 
o/1]2i13]4/5 |6/7/i/84]91]atsb+ilctlaitled ft 


63 |7c |77 |7b_ | f2 6b |6f {cS 30 /01 |67 |2b | fe d7 |ab | 76 
ca 82 |c9 7d | fa 59 |47 | f0 ad d4 |a2 /af 9c a4 |72 |cO 
b7 | fd 93 |26 |/36 |3f | f7 cc 34 {a5 |e5 |f1 71 |d8 | 31 15 
04 /|c7 23 | c3 18 |96 |05 |9a |07 |12 |80 |je2 |eb |27 |b2 |75 
09 /|83 | 2c la |1b |6e |5a /|a0 |52 |3b |d6 |b3 |29 |e3 |2f | 84 
5b |6a | cb be 39 |4a | 4c 58 | cf 

dO |ef aa_ | fb 43 |4d |33 /|85 |45 | f9 02 |7f 50 |3c_ | 9f a8 
51 ;a3 |40 | 8f 92 |9d |38 | f5 bc b6 /|da /|21 10 ‘| ff f3 d2 
cd Oc 13° | ec 5f (97 |44 |17 |c4 |a7 |7e |3d |64 |5d |19 | 73 
60 /|81 /|4f | dc 22 |;2a |90 |88 |46 |ee |b8 |14 |de |5e |Ob_ | db 
eO |32 |3a |Oa |49 |06 |24 |5c |c2 /|d3 Jac 62 /91 /95 |e4 |79 
a9 | 6c 56 | f4 ea 65 |7a |ae 08 
ba 78 |25 |2e Ic a6 | b4 = |c6 e8 | dd 74 =| 1f 4b |bd /|8b | 8a 
Oe /|61 35 /57 |b9 |86 |cl Id | 9e 
el 8 98 |11 |69 |d9 |8e |94 |9b |1e |87 |e9 |ce 55 |28 | df 

8c /al 89 |Od | bf e6 |42 |68 /|41 |/99 |2d_ | Of bo /54 |bb | 16 
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SubWord(): produces an output AES word (four bytes) from the four bytes of an input word using a non-linear 
substitution table (S-BOX). 
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X'Tj] = ( $'(3, j) s'(2, ps S‘(1, j); s‘(0, j) ) = ( S-Box (S(3, j)), S-Box( S(2, j) )s S-Box( S(1, j) )s S-Box( 
S(0, j) )) 

InvMixColumns(): The inverse transformation of MixColumns(). 

The InvMixColumns() transformation defines the relationship between each byte of the result state S’(i, j) as 
a function of input state bytes, S(i, j), by 

S'(0, j) := FF_MUL( OeH, S(0, j) ) XOR FF_MUL(ObH, S(1, j) ) XOR FF_MUL(OdH, S(2, j) ) XOR FF_MUL( 09H, 
S(3, j) ) 

S'(1, j) := FF_MUL(09H, S(O, j) ) XOR FF_MUL( OeH, S(1, j) ) XOR FF_MUL(ObH, S(2, j) ) XOR FF_MUL( OdH, 
S(3, j) ) 

S'(2, j) := FF_MUL(OdH, S(O, j) ) XOR FF_MUL( 09H, S(1, j) ) XOR FF_MUL( OeH, S(2, j) ) XOR FF_MUL(ObH, 
S(3, j) ) 

S'(3, j) := FF_MUL(ObH, S(O, j) ) XOR FF_MUL(OdH, S(1, j) ) XOR FF_MUL( 09H, S(2, j) ) XOR FF_MUL( OeH, 
S(3, j) ), where j = 0, 1, 2, 3. 

InvShiftRows(): The inverse transformation of InvShiftRows(). The InvShiftRows() transforms the matrix 


representation of a 16-byte AES state by cyclically shifting the last three rows of the state by different offset to 
the right, see Table 12-14. 


Table 12-14. The InvShiftRows Transformation 


Matrix Representation of Input State Output of ShiftRows 
A E | M A E | M 
B F J N N B F J 
C G K ) K 0) C G 
D H L P H L P D 


InvSubBytes(): The inverse transformation of SubBytes(). 


The InvSubBytes() transformation defines the relationship between each byte of the result state S’(i, j) as a 
function of input state byte S(i, j), by 


S'(i, j) := InvS-Box (S(i, j)[7:4], S(i, j)[3:0]) 


where InvS-BOX (S[7:4], S[3:0]) represents a look-up operation on a 16x16 table to return a byte value, see 
Table 12-15. 
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Table 12-15. Look-up Table Associated with InvS-Box Transformation 
S[3:0] 
0 1 2 3 4 5 6 7 8 9 a b C d e f 


0 52 ;09 |6a |d5 |30 /|36 |a5 | 38 | bf 40 |a3 |9e | 81 | f3 d7 | fb 
1 7c je3 |39 |82 |9b /|2f | ff 87 |34 |8e |/43 |44 |c4 |de /|e9 (cb 
2 54 |7b |94 |32 |a6 |c2 23 |3d jee |4c |95 |Ob | 42 | fa c3.s| 4e 
3 08 |2e /|al 66 |28 |d9 |24 |b2 |76 |5b |a2 |49 |6d |8b /d1 25 
4 72 | f8 f6 64 /86 |68 |98 |16 |d4 |/a4 |5c jcc 5d |65 |b6 | 92 
5 6c |70 |48 |50 | fd ed |b9 /|da |5e |15 |46 |57 |a7 |8d |9d | 84 
6 90 |d8 |ab |00 |8c |be /|d3 |0a_ | f7 e4 /58 /05 |b8 |b3 |45 /| 06 
s[7:4] 7 dO /|2c le |8f /|ca 3f Of |02 |cl af bd /03 |01 13. |8a | 6b 
8 3a /|91 11 41 4f 67 | dc ea 97 | f2 cf ce f0 b4 |e6 | 73 
9 96 | ac 74 |22 |e7 |ad |35 |85 |e2 | f9 37 |e8 |1c |75 | df 6e 
a 47 |f1 la |71 Id |29 /|cS |89 |6f |b7 |62 |Oe jaa 18 |be | 1b 
b fc 56 |3e |4b /|c6 d2 |79 |20 |9a |db |cO | fe 78 |cd 5a_ | f4 
c 1f |dd /|a8 |33 |88 |07 |c7 31 |b1 12 |10 |59 |27 |80 |ec of 
d 60 /|51 7f |a9 |19 |b5 |4a |Od |2d |e5 |7a |9Ff |93 |c9 |9c_ | ef 
e aO |eO |3b |4d | ae 2a_ | f5 bo |c8 eb | bb 3c 83 |53 /|99 | 61 
f 17. |2b |04 |7e |ba |77 |d6 |26 |e1 69 |14 (|63 |55 |21 |Oc | 7d 


12.13.3 PCLMULQDQ 


The PCLMULQDQ instruction performs carry-less multiplication of two 64-bit data into a 128-bit result. Carry-less 
multiplication of two 128-bit data into a 256-bit result can use PCLMULQDQ as building blocks. 


Carry-less multiplication is a component of many cryptographic systems. It is an important piece of implementing 
Galois Counter Mode (GCM) operation of block ciphers. GCM operation can be used in conjunction with AES algo- 
rithms to add authentication capability. GCM usage models also include IPsec, storage standard, and security 
protocols over fiber channel. Additionally, PCLMULQDQ can be used in calculations of hash functions and CRC using 
arbitrary polynomials. 


12.13.4 Checking for AESNI Support 


Before an application attempts to use AESNI instructions or PCLMULQDQ, the application should follow the steps 
illustrated in Section 11.6.2, “Checking for SSE/SSE2 Support.” Next, use the additional step provided below: 


Check that the processor supports AESNI (if CPUID.01H:ECX.AESNI[bit 25] = 1); check that the processor 
supports PCLMULQDQ (if CPUID.01H:ECX.PCLMULQDQ[bit 1] = 1). 


12-24 Vol.1 


CHAPTER 13 
MANAGING STATE USING THE XSAVE FEATURE SET 


The XSAVE feature set extends the functionality of the FXSAVE and FXRSTOR instructions (see Section 10.5, 
“FXSAVE and FXRSTOR Instructions”) by supporting the saving and restoring of processor state in addition to the 
x87 execution environment (x87 state) and the registers used by the streaming SIMD extensions (SSE state). 


The XSAVE feature set comprises eight instructions. XGETBV and XSETBV allow software to read and write the 
extended control register XCRO, which controls the operation of the XSAVE feature set. XSAVE, XSAVEOPT, 
XSAVEC, and XSAVES are four instructions that save processor state to memory; XRSTOR and XRSTORS are corre- 
sponding instructions that load processor state from memory. XGETBV, XSAVE, XSAVEOPT, XSAVEC, and XRSTOR 
can be executed at any privilege level; XSETBV, XSAVES, and XRSTORS can be executed only if CPL = 0. In addition 
to XCRO, the XSAVES and XRSTORS instructions are controlled also by the IA32_XSS MSR (index DAOH). 


The XSAVE feature set organizes the state that manages into state components. Operation of the instructions is 
based on state-component bitmaps that have the same format as XCRO and as the IA32_XSS MSR: each bit 
corresponds to a state component. Section 13.1 discusses these state components and bitmaps in more detail. 


Section 13.2 describes how the processor enumerates support for the XSAVE feature set and for XSAVE-enabled 
features (those features that require use of the XSAVE feature set for their enabling). Section 13.3 explains how 
software can enable the XSAVE feature set and XSAVE-enabled features. 


The XSAVE feature set allows saving and loading processor state from a region of memory called an XSAVE area. 
Section 13.4 presents details of the XSAVE area and its organization. Each XSAVE-managed state component is 
associated with a section of the XSAVE area. Section 13.5 describes in detail each of the XSAVE-managed state 
components. 


Section 13.7 through Section 13.12 describe the operation of XSAVE, XRSTOR, XSAVEOPT, XSAVEC, XSAVES, and 
XRSTORS, respectively. 


13.1. XSAVE-SUPPORTED FEATURES AND STATE-COMPONENT BITMAPS 


The XSAVE feature set supports the saving and restoring of state components, each of which is a discrete set of 
processor registers (or parts of registers). In general, each such state component corresponds to a particular CPU 
feature. Such a feature is XSAVE-supported. Some XSAVE-supported features use registers in multiple XSAVE- 
managed state components. 


The XSAVE feature set organizes the state components of the XSAVE-supported features using state-component 
bitmaps. A state-component bitmap comprises 64 bits; each bit in such a bitmap corresponds to a single state 
component. The following bits are defined in state-component bitmaps: 


¢ Bit 0 corresponds to the state component used for the x87 FPU execution environment (x87 state). See 
Section 13.5.1. 


¢ Bit 1 corresponds to the state component used for registers used by the streaming SIMD extensions (SSE 
state). See Section 13.5.2. 


* Bit 2 corresponds to the state component used for the additional register state used by the Intel® Advanced 
Vector Extensions (AVX state). See Section 13.5.3. 


* Bits 4:3 correspond to the two state components used for the additional register state used by Intel® Memory 
Protection Extensions (MPX state): 


— State component 3 is used for the 4 128-bit bounds registers BNDO-BND3 (BNDREGS state). 


— State component 4 is used for the 64-bit user-mode MPX configuration register BNDCFGU and the 64-bit 
MPX status register BNDSTATUS (BNDCSR state). 


* Bits 7:5 correspond to the three state components used for the additional register state used by Intel® 
Advanced Vector Extensions 512 (AVX-512 state): 


— State component 5 is used for the 8 64-bit opmask registers kKO-k7 (opmask state). 
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— State component 6 is used for the upper 256 bits of the registers ZMMO-ZMM15. These 16 256-bit values 
are denoted ZMMO_H-ZMM15_H (ZMM_Hi256 state). 


— State component 7 is used for the 16 512-bit registers ZMM16-ZMM31 (Hi16_ZMM state). 
¢ Bit 8 corresponds to the state component used for the Intel Processor Trace MSRs (PT state). 


® Bit 9 corresponds to the state component used for the protection-key feature’s register PKRU (PKRU state). 
See Section 13.5.7. 


¢ Bits 12:11 correspond to the two state components used for the additional register state used by Control-Flow 
Enforcement Technology (CET state): 


— State component 11 is used for the 2 MSRs controlling user-mode functionality for CET (CET_U state). 


— State component 12 is used for the 3 MSRs containing shadow-stack pointers for privilege levels 0-2 
(CET_S state). 


¢ Bit 13 corresponds to the state component used for an MSR used to control hardware duty cycling (HDC 
state). See Section 13.5.9. 


¢ Bit 16 corresponds to the state component used for an MSR used to control hardware P-states (HWP state). 
See Section 13.5.10. 


Bit 10, bits 15:14, and bits in the range 62:17 are not currently defined in state-component bitmaps and are 
reserved for future expansion. As individual state components are defined using those bits, additional sub-sections 
will be updated within Section 13.5 over time. Bit 63 is used for special functionality in some bitmaps and does not 
correspond to any state component. 


The state component corresponding to bit / of state-component bitmaps is called state component /. Thus, x87 
state is state component 0; SSE state is state component 1; AVX state is state component 2; MPX state comprises 
state components 3-4; AVX-512 state comprises state components 5-7; PT state is state component 8; PKRU 
state is state component 9; CET state comprises state components 11-12; HDC state is state component 13; and 
HWP state is state component 16. 


The XSAVE feature set uses state-component bitmaps in multiple ways. Most of the instructions use an implicit 
operand (in EDX:EAX), called the instruction mask, which is the state-component bitmap that specifies the state 
components on which the instruction operates. 


Some state components are user state components, and they can be managed by the entire XSAVE feature set. 
Other state components are supervisor state components, and they can be managed only by XSAVES and 
XRSTORS. The state components corresponding to bit 9 and to bits in the range 7:0 are user state components; 
those corresponding to bit 8, to bits in the range 13:11, and to bit 16 are supervisor state components. 


Extended control register XCRO contains a state-component bitmap that specifies the user state components that 
software has enabled the XSAVE feature set to manage. If the bit corresponding to a state component is clear in 
XCRO, instructions in the XSAVE feature set will not operate on that state component, regardless of the value of the 
instruction mask. 


The IA32_XSS MSR (index DAOH) contains a state-component bitmap that specifies the supervisor state compo- 
nents that software has enabled XSAVES and XRSTORS to manage (XSAVE, XSAVEC, XSAVEOPT, and XRSTOR 
cannot manage supervisor state components). If the bit corresponding to a state component is clear in the 
IA32_XSS MSR, XSAVES and XRSTORS will not operate on that state component, regardless of the value of the 
instruction mask. 


Some XSAVE-supported features can be used only if XCRO has been configured so that the features’ state compo- 
nents can be managed by the XSAVE feature set. (This applies only to features with user state components.) Such 
state components and features are XSAVE-enabled. In general, the processor will not modify (or allow modifica- 
tion of) the registers of a state component of an XSAVE-enabled feature if the bit corresponding to that state 
component is clear in XCRO. (If software clears such a bit in XCRO, the processor preserves the corresponding state 
component.) If an XSAVE-enabled feature has not been fully enabled in XCRO, execution of any instruction defined 
for that feature causes an invalid-opcode exception (#UD). 


As will be explained in Section 13.3, the XSAVE feature set is enabled only if CR4.OSXSAVE[bit 18] = 1. If 
CR4.OSXSAVE = 0, the processor treats XSAVE-enabled state features and their state components as if all bits in 
XCRO were clear; the state components cannot be modified and the features’ instructions cannot be executed. 


The state components for x87 state, for SSE state, for PT state, for PKRU state, for CET state, for HDC state, and 
for HWP state are XSAVE-managed but the corresponding features are not XSAVE-enabled. Processors allow modi- 
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fication of this state, as well as execution of x87 FPU instructions and SSE instructions and use of Intel Processor 
Trace, protection keys, CET, hardware duty cycling, and hardware P-states regardless of the value of CR4.0SXSAVE 


and XCRO. 


13.2 


ENUMERATION OF CPU SUPPORT FOR XSAVE INSTRUCTIONS AND XSAVE- 
SUPPORTED FEATURES 


A processor enumerates support for the XSAVE feature set and for features supported by that feature set using the 
CPUID instruction. The following items provide specific details: 


¢ CPUID.1:ECX.XSAVE[bit 26] enumerates general support for the XSAVE feature set: 


— If this bit is 0, the processor does not support any of the following instructions: XGETBV, XRSTOR, 
XRSTORS, XSAVE, XSAVEC, XSAVEOPT, XSAVES, and XSETBV; the processor provides no further 
enumeration through CPUID function ODH (see below). 


— If this bit is 1, the processor supports the following instructions: XGETBV, XRSTOR, XSAVE, and XSETBV.! 
Further enumeration is provided through CPUID function ODH. 


CR4.OSXSAVE can be set to 1 if and only if CPUID.1:ECX.XSAVE[bit 26] is enumerated as 1. 


¢ CPUID function ODH enumerates details of CPU support through a set of sub-functions. Software selects a 
specific sub-function by the value placed in the ECX register. The following items provide specific details: 


— CPUID function ODH, sub-function 0. 


EDX:EAX is a bitmap of all the user state components that can be managed using the XSAVE feature 
set. A bit can be set in XCRO if and only if the corresponding bit is set in this bitmap. Every processor 
that supports the XSAVE feature set will set EAX[0] (x87 state) and EAX[1] (SSE state). 


If EAX[/] = 1 (for 1 <i < 32) or EDX[/-32] = 1 (for 32 < i < 63), sub-function / enumerates details for 
state component / (see below). 


ECX enumerates the size (in bytes) required by the XSAVE instruction for an XSAVE area containing all 
the user state components supported by this processor. 


EBX enumerates the size (in bytes) required by the XSAVE instruction for an XSAVE area containing all 
the user state components corresponding to bits currently set in XCRO. 


— CPUID function ODH, sub-function 1. 


EAX[0] enumerates support for the XSAVEOPT instruction. The instruction is supported if and only if 
this bit is 1. If EAX[O0] = 0, execution of XSAVEOPT causes an invalid-opcode exception (#UD). 


EAX[1] enumerates support for compaction extensions to the XSAVE feature set. The following are 
supported if this bit is 1: 


— The compacted format of the extended region of XSAVE areas (see Section 13.4.3). 
— The XSAVEC instruction. If EAX[1] = 0, execution of XSAVEC causes a #UD. 
— Execution of the compacted form of XRSTOR (see Section 13.8). 


EAX[2] enumerates support for execution of XGETBV with ECX = 1. This allows software to determine 
the state of the init optimization. See Section 13.6. 


EAX[3] enumerates support for XSAVES, XRSTORS, and the IA32_XSS MSR. If EAX[3] = 0, execution 
of XSAVES or XRSTORS causes a #UD; an attempt to access the IA32_XSS MSR using RDMSR or 
WRMSR causes a general-protection exception (#GP). Every processor that supports a supervisor state 
component sets EAX[3]. Every processor that sets EAX[3] (XSAVES, XRSTORS, IA32_XSS) will also set 
EAX[1] (the compaction extensions). 


EAX[31:4] are reserved. 


1. If CPUID.1:ECX.XSAVE[bit 26] = 1, XGETBV and XSETBV may be executed with ECX = 0 (to read and write XCRO). Any support for 
execution of these instructions with other values of ECX is enumerated separately. 
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¢ EBX enumerates the size (in bytes) required by the XSAVES instruction for an XSAVE area containing all 
the state components corresponding to bits currently set in XCRO | IA32_XSS. 


¢ EDX:ECX is a bitmap of all the supervisor state components that can be managed by XSAVES and 
XRSTORS. A bit can be set in the IA32_XSS MSR if and only if the corresponding bit is set in this bitmap. 


NOTE 


In summary, the XSAVE feature set supports state component / (0 < / < 63) if one of the following 
is true: (1) i < 32 and CPUID.(EAX=0DH,ECX=0):EAX[/] = 1; (2) i = 32 and 
CPUID.(EAX=0DH,ECX=0):EAX[i-32] = 1; (3) i < 32 and CPUID.(EAX=0DH,ECX=1):ECX[/] = 1; 
or (4) i = 32 and CPUID.(EAX=0DH,ECX=1):EDX[/-32] = 1. The XSAVE feature set supports user 
state component / if (1) or (2) holds; if (3) or (4) holds, state component / is a supervisor state 
component and support is limited to XSAVES and XRSTORS. 


CPUID function ODH, sub-function / (i > 1). This sub-function enumerates details for state component /. If 
the XSAVE feature set supports state component / (see note above), the following items provide specific 
details: 


¢ EAX enumerates the size (in bytes) required for state component /. 


¢ If state component / is a user state component, EBX enumerates the offset (in bytes, from the base of 
the XSAVE area) of the section used for state component /. (This offset applies only when the standard 
format for the extended region of the XSAVE area is being used; see Section 13.4.3.) 


¢ If state component / is a supervisor state component, EBX returns 0. 


¢ If state component / is a user state component, ECX[0] return 0; if state component / is a supervisor 
state component, ECX[0] returns 1. 


¢ The value returned by ECX[1] indicates the alignment of state component / when the compacted format 
of the extended region of an XSAVE area is used (see Section 13.4.3). If ECX[1] returns 0, state 
component / is located immediately following the preceding state component; if ECX[1] returns 1, state 
component / is located on the next 64-byte boundary following the preceding state component. 


¢ ECX[31:2] and EDX return 0. 


If the XSAVE feature set does not support state component /, sub-function / returns 0 in EAX, EBX, ECX, and 
EDX. 


ENABLING THE XSAVE FEATURE SET AND XSAVE-ENABLED FEATURES 


Software enables the XSAVE feature set by setting CR4.OSXSAVE[bit 18] to 1 (e.g., with the MOV to CR4 instruc- 
tion). If this bit is 0, execution of any of XGETBV, XRSTOR, XRSTORS, XSAVE, XSAVEC, XSAVEOPT, XSAVES, and 
XSETBV causes an invalid-opcode exception (#UD). 


When CR4.0SXSAVE = 1 and CPL = 0, executing the XSETBV instruction with ECX = 0 writes the 64-bit value in 
EDX:EAX to XCRO (EAX is written to XCRO[31:0] and EDX to XCRO[63:32]). (Execution of the XSETBV instruction 
causes a general-protection fault — #GP — if CPL > 0.) The following items provide details regarding individual bits 
in XCRO: 


XCRO[0] is associated with x87 state (see Section 13.5.1). XCRO[O] is always 1. It has that value coming out of 
RESET. Executing the XSETBV instruction causes a general-protection fault (#GP) if ECX = 0 and EAX[0] is 0. 


XCRO[1] is associated with SSE state (see Section 13.5.2). Software can use the XSAVE feature set to manage 
SSE state only if XCRO[1] = 1. The value of XCRO[1] in no way determines whether software can execute SSE 
instructions (these instructions can be executed even if XCRO[1] = 0). 


XCRO[1] is 0 coming out of RESET. As noted in Section 13.2, every processor that supports the XSAVE feature 
set allows software to set XCRO[1]. 


XCRO[2] is associated with AVX state (see Section 13.5.3). Software can use the XSAVE feature set to manage 
AVX state only if XCRO[2] = 1. In addition, software can execute AVX instructions only if CR4.0SXSAVE = 
XCRO[2] = 1. Otherwise, any execution of an AVX instruction causes an invalid-opcode exception (#UD). 
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XCRO[2] is 0 coming out of RESET. As noted in Section 13.2, a processor allows software to set XCRO[2] if and 
only if CPUID.(EAX=0DH,ECX=0):EAX[2] = 1. In addition, executing the XSETBV instruction causes a general- 
protection fault (#GP) if ECX = 0 and EAX[2:1] has the value 10b; that is, software cannot enable the XSAVE 
feature set for AVX state but not for SSE state. 


As noted in Section 13.1, the processor will preserve AVX state unmodified if software clears XCRO[2]. 
However, clearing XCRO[2] while AVX state is not in its initial configuration may cause SSE instructions to incur 
a power and performance penalty. See Section 13.5.3, “Enable the Use Of XSAVE Feature Set And XSAVE State 
Components” of Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, for how system 
software can avoid this penalty. 


¢  XCRO[4:3] are associated with MPX state (see Section 13.5.4). Software can use the XSAVE feature set to 
manage MPxX state only if XCRO[4:3] = 11b. In addition, MPX instructions operate as defined only if 
CR4.OSXSAVE = 1 and XCRO[4:3] = 11b. Otherwise, execution of an MPX instruction causes no operation (as 
a NOP instruction); in addition, executions of CALL, RET, JMP, and Jcc do not initialize the bounds registers, and 
they ignore any F2H (BND) prefix.? 


XCRO[4:3] have value 00b coming out of RESET. As noted in Section 13.2, a processor allows software to set 
XCRO[4:3] to 11b if and only if CPUID.(EAX=0DH,ECX=0):EAX[4:3] = 11b. In addition, executing the XSETBV 
instruction causes a general-protection fault (#GP) if ECX = 0, EAX[4:3] is neither 00b nor 11b; that is, 
software can enable the XSAVE feature set for MPX state only if it does so for both state components. 


As noted in Section 13.1, the processor will preserve MPX state unmodified if software clears XCRO[4:3]. 


¢  XCRO[7:5] are associated with AVX-512 state (see Section 13.5.5). Software can use the XSAVE feature set to 
manage AVX-512 state only if XCRO[7:5] = 111b. In addition, software can execute AVX-512 instructions only 
if CR4.0OSXSAVE = 1 and XCRO[7:5] = 111b. Otherwise, any execution of an AVX-512 instruction causes an 
invalid-opcode exception (#UD). 


XCRO[7:5] have value 000b coming out of RESET. As noted in Section 13.2, a processor allows software to set 
XCRO[7:5] to 111b if and only if CPUID.(EAX=0DH,ECX=0):EAX[7:5] = 111b. In addition, executing the 
XSETBV instruction causes a general-protection fault (#GP) if ECX = 0, EAX[7:5] is not 000b, and any bit is 
clear in EAX[2:1] or EAX[7:5]; that is, software can enable the XSAVE feature set for AVX-512 state only if it 
does so for all three state components, and only if it also does so for AVX state and SSE state. This implies that 
the value of XCRO[7:5] is always either 000b or 111b. 


As noted in Section 13.1, the processor will preserve AVX-512 state unmodified if software clears XCRO[7:5]. 
However, clearing XCRO[7:5] while AVX-512 state is not in its initial configuration may cause SSE and AVX 
instructions to incur a power and performance penalty. See Section 13.5.3, “Enable the Use Of XSAVE Feature 
Set And XSAVE State Components” of Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 
3A, for how system software can avoid this penalty. 


¢  XCRO[9] is associated with PKRU state (see Section 13.5.7). Software can use the XSAVE feature set to 
manage PKRU state only if XCRO[9] = 1. The value of XCRO[9] in no way determines whether software can use 
protection keys or execute other instructions that access PKRU state (these instructions can be executed even 
if XCRO[9] = 0). 


XCRO[9] is 0 coming out of RESET. As noted in Section 13.2, a processor allows software to set XCRO[9] if and 
only if CPUID.(EAX=0DH,ECX=0):EAX[9] = 1. 


* XCRO[63:10] and XCRO[8] are reserved.” Executing the XSETBV instruction causes a general-protection fault 
(#GP) if ECX = 0 and any corresponding bit in EDX:EAX is not 0. These bits in XCRO are all 0 coming out of 
RESET. 


Software operating with CPL > 0 may need to determine whether the XSAVE feature set and certain XSAVE- 
enabled features have been enabled. If CPL > 0, execution of the MOV from CR4 instruction causes a general- 
protection fault (#GP). The following alternative mechanisms allow software to discover the enabling of the XSAVE 
feature set regardless of CPL: 


1. Prior to the introduction of MPX, the opcodes defining MPX instructions operated as NOP, and the CALL, RET, JMP, and Jcc instruc- 
tions ignored any F2H prefix. 


2. Bit 8 and bits 13:11 correspond to supervisor state components. Since bits can be set in XCRO only for user state components, 
those bits of XCRO must be O. 
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° The value of CR4.OSXSAVE is returned in CPUID.1:ECX.OSXSAVE[bit 27]. If software determines that 
CPUID.1:ECX.OSXSAVE = 1, the processor supports the XSAVE feature set and the feature set has been 
enabled in CR4. 


¢ Executing the XGETBV instruction with ECX = 0 returns the value of XCRO in EDX:EAX. XGETBV can be 
executed if CR4.OSXSAVE = 1 (if CPUID.1:ECX.OSXSAVE = 1), regardless of CPL. 


Thus, software can use the following algorithm to determine the support and enabling for the XSAVE feature set: 
1. Use CPUID to discover the value of CPUID.1:ECX.OSXSAVE. 


— Ifthe bit is 0, either the XSAVE feature set is not supported by the processor or has not been enabled by 
software. Either way, the XSAVE feature set is not available, nor are XSAVE-enabled features such as AVX. 


— Ifthe bit is 1, the processor supports the XSAVE feature set — including the XGETBV instruction — and it 
has been enabled by software. The XSAVE feature set can be used to manage x87 state (because XCRO[0] 
is always 1). Software requiring more detailed information can go on to the next step. 


2. Execute XGETBV with ECX = 0 to discover the value of XCRO. If XCRO[1] = 1, the XSAVE feature set can be 
used to manage SSE state. If XCRO[2] = 1, the XSAVE feature set can be used to manage AVX state and 
software can execute AVX instructions. If XCRO[4:3] is 11b, the XSAVE feature set can be used to manage MPX 
state and software can execute MPX instructions. If XCRO[7:5] is 111b, the XSAVE feature set can be used to 
manage AVX-512 state and software can execute AVX-512 instructions. If XCRO[9] = 1, the XSAVE feature set 
can be used to manage PKRU state. 


The IA32_XSS MSR (with MSR index DAOH) is zero coming out of RESET. If CR4.0OSXSAVE = 1, 
CPUID.(EAX=0DH,ECX=1):EAX[3] = 1, and CPL = 0, executing the WRMSR instruction with ECX = DAOH writes 
the 64-bit value in EDX:EAX to the IA32_XSS MSR (EAX is written to IA32_XSS[31:0] and EDX to 
IA32_XSS[63:32]). The following items provide details regarding individual bits in the IA32_XSS MSR: 

e JTA32_XSS[8] is associated with PT state (see Section 13.5.6). Software can use XSAVES and XRSTORS to 
manage PT state only if IA32_XSS[8] = 1. The value of IA32_XSS[8] does not determine whether software can 
use Intel Processor Trace (the feature can be used even if IA32_XSS[8] = 0). 

® JA32_XSS[12:11] are associated with CET state (see Section 13.5.8), IA32_XSS[11] with CET_U state and 
IA32_XSS[12] with CET_S state. Software can use the XSAVES and XRSTORS to manage CET_U state (respec- 
tively, CET_S state) only if IA32_XSS[11] = 1 (respectively, IA32_XSS[12] = 1). The value of 
IA32_XSS[12:11] does not determine whether software can use CET (the feature can be used even if either of 
IA32_XSS[12:11] is 0). 

e JTA32_XSS[13] is associated with HDC state (see Section 13.5.9). Software can use XSAVES and XRSTORS to 
manage HDC state only if IA32_XSS[13] = 1. The value of IA32_XSS[13] does not determine whether software 
can use hardware duty cycling (the feature can be used even if IA32_XSS[13] = 0). 

¢ JA32_XSS[16] is associated with HWP state (see Section 13.5.10). Software can use XSAVES and XRSTORS to 
manage HWP state only if IA32_XSS[16] = 1. The value of IA32_XSS[16] does not determine whether 
software can use hardware P-states (the feature can be used even if IA32_XSS[16] = 0). 

* 1A32_XSS[63:17], IA32_XSS[15:14], IA32_XSS[10:9] and IA32_XSS[7:0] are reserved.! Executing the 
WRMSR instruction causes a general-protection fault (4#GP) if ECX = DAOH and any corresponding bit in 
EDX:EAX is not 0. These bits in XCRO are all 0 coming out of RESET. 


The IA32_XSS MSR is 0 coming out of RESET. 
There is no mechanism by which software operating with CPL > 0 can discover the value of the IA32_XSS MSR. 


13.4 XSAVE AREA 


The XSAVE feature set includes instructions that save and restore the XSAVE-managed state components to and 
from memory: XSAVE, XSAVEOPT, XSAVEC, and XSAVES (for saving); and XRSTOR and XRSTORS (for restoring). 
The processor organizes the state components in a region of memory called an XSAVE area. Each of the save and 


1. Bit 9 and bits 7:0 correspond to user state components. Since bits can be set in the [A32_XSS MSR only for supervisor state compo- 
nents, those bits of the MSR must be 0. 
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restore instructions takes a memory operand that specifies the 64-byte aligned base address of the XSAVE area on 
which it operates. 


Every XSAVE area has the following format: 


¢ The legacy region. The legacy region of an XSAVE area comprises the 512 bytes starting at the area’s base 
address. It is used to manage the state components for x87 state and SSE state. The legacy region is described 
in more detail in Section 13.4.1. 


° The XSAVE header. The XSAVE header of an XSAVE area comprises the 64 bytes starting at an offset of 512 
bytes from the area’s base address. The XSAVE header is described in more detail in Section 13.4.2. 


¢ The extended region. The extended region of an XSAVE area starts at an offset of 576 bytes from the area’s 
base address. It is used to manage the state components other than those for x87 state and SSE state. The 
extended region is described in more detail in Section 13.4.3. The size of the extended region is determined by 
which state components the processor supports and which bits have been set in XCRO and IA32_XSS (see 
Section 13.3). 


13.4.1 Legacy Region of an XSAVE Area 


The legacy region of an XSAVE area comprises the 512 bytes starting at the area’s base address. It has the same 
format as the FXSAVE area (see Section 10.5.1). The XSAVE feature set uses the legacy area for x87 state (state 
component 0) and SSE state (state component 1). Table 13-1 illustrates the format of the first 416 bytes of the 
legacy region of an XSAVE area. 


Table 13-1. Format of the Legacy Region of an XSAVE Area 


FIP[63:48] or FCS or 
reserved FIP[47:32] 


FIP[31:0] 


FDP[63:48] FDS or 


MXCSR_MASK MXCSR orreserved | FDP[47:32] 


FDP[31:0] 


Reserved ST0O/MMO 
Reserved ST1/MM1 


Reserved ST2/MM2 


Reserved ST3/MM3 
Reserved ST4/MM4 


Reserved ST5/MM5 


Reserved ST6/MM6 


Reserved ST7/MM7 


XMM5 240 
XMM6 256 
XMM7 272 
XMM8 288 
XMM9 304 
XMM10 320 
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Table 13-1. Format of the Legacy Region of an XSAVE Area (Contd.) (Contd.) 


The x87 state component comprises bytes 23:0 and bytes 159:32. The SSE state component comprises 
bytes 31:24 and bytes 415:160. The XSAVE feature set does not use bytes 511:416; bytes 463:416 are reserved. 


Section 13.7 through Section 13.9 provide details of how instructions in the XSAVE feature set use the legacy 
region of an XSAVE area. 


13.4.2 XSAVE Header 


The XSAVE header of an XSAVE area comprises the 64 bytes starting at offset 512 from the area’s base address: 


¢ Bytes 7:0 of the XSAVE header is a state-component bitmap (see Section 13.1) called XSTATE_BV. It 
identifies the state components in the XSAVE area. 


° Bytes 15:8 of the XSAVE header is a state-component bitmap called XCOMP_BV. It is used as follows: 


— XCOMP_BV[63] indicates the format of the extended region of the XSAVE area (see Section 13.4.3). If it is 
clear, the standard format is used. If it is set, the compacted format is used; XCOMP_BV[62:0] provide 
format specifics as specified in Section 13.4.3. 


— XCOMP_BV[63] determines which form of the XRSTOR instruction is used. If the bit is set, the compacted 
form is used; otherwise, the standard form is used. See Section 13.8. 


— All bits in XCOMP_BV should be 0 if the processor does not support the compaction extensions to the XSAVE 
feature set. 


° Bytes 63:16 of the XSAVE header are reserved. 


Section 13.7 through Section 13.9 provide details of how instructions in the XSAVE feature set use the XSAVE 
header of an XSAVE area. 


13.4.3 Extended Region of an XSAVE Area 


The extended region of an XSAVE area starts at byte offset 576 from the area’s base address. The size of the 
extended region is determined by which state components the processor supports and which bits have been set in 
XCRO | IA32_XSS (see Section 13.3). 


The XSAVE feature set uses the extended area for each state component /, where i > 2. The following state compo- 
nents are currently supported in the extended area: state component 2 contains AVX state; state components 5-7 
contain AVX-512 state; and state component 9 contains PKRU state. 


The extended region of the an XSAVE area may have one of two formats. The standard format is supported by all 
processors that support the XSAVE feature set; the compacted format is supported by those processors that 
support the compaction extensions to the XSAVE feature set (see Section 13.2). Bit 63 of the XCOMP_BV field in 
the XSAVE header (see Section 13.4.2) indicates which format is used. 


The following items describe the two possible formats of the extended region: 


* Standard format. Each state component / (/ = 2) is located at the byte offset from the base address of the 
XSAVE area enumerated in CPUID.(EAX=0DH,ECX=/):EBX. (CPUID.(EAX=0DH,ECX=/):EAX enumerates the 
number of bytes required for state component /. 


¢ Compacted format. Each state component i (i > 2) is located at a byte offset from the base address of the 
XSAVE area based on the XCOMP_BV field in the XSAVE header: 
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— If XCOMP_BV[/] = 0, state component jis not in the XSAVE area. 


— If XCOMP_BV[/] = 1, state component / is located at a byte offset /ocation; from the base address of the 
XSAVE area, where /ocation; is determined by the following items: 


* If XCOMP_BV[j] = 0 for every j, 2 <j < i, location; is 576. (This item applies if / is the first bit set in 
bits 62:2 of the XCOMP_BV; it implies that state component / is located at the beginning of the 
extended region.) 


¢ Otherwise, let j, 2 <j <i, be the greatest value such that XCOMP_BV[j] = 1. Then /ocation, is 
determined by the following values: /ocation,;; size;, as enumerated in CPUID.(EAX=0DH,ECX=j):EAX; 
and the value of align;, as enumerated in CPUID.(EAX=0DH,ECX=/):ECX[1]: 


— Tf align; = 0, location; = location; + size. (This item implies that state component / is located 
immediately following the preceding state component whose bit is set in XCOMP_BV.) 


— Tf align; = 1, location; = ceiling(/location, + size;, 64). (This item implies that state component j is 
located on the next 64-byte boundary following the preceding state component whose bit is set in 
XCOMP_BV.) 


13.5 XSAVE-MANAGED STATE 


The section provides details regarding how the XSAVE feature set interacts with the various XSAVE-managed state 
components. 


Unless otherwise state, the state pertaining to a particular state component is saved beginning at byte 0 of the 
section of the XSAVE are corresponding to that state component. 


13.5.1 x87 State 


Instructions in the XSAVE feature set can manage the same state of the x87 FPU execution environment (x87 
state) that can be managed using the FXSAVE and FXRSTOR instructions. They organize all x87 state as a user 
state component in the legacy region of the XSAVE area (see Section 13.4.1). This region is illustrated in 

Table 13-1; the x87 state is listed below, along with details of its interactions with the XSAVE feature set: 


¢ Bytes 1:0, 3:2, 7:6. These are used for the x87 FPU Control Word (FCW), the x87 FPU Status Word (FSW), and 
the x87 FPU Opcode (FOP), respectively. 


¢ Byte 4 is used for an abridged version of the x87 FPU Tag Word (FTW). The following items describe its usage: 


— For eachj, 0 <j <7, XSAVE, XSAVEOPT, XSAVEC, and XSAVES save a 0 into bit j of byte 4 if x87 FPU data 
register STj has a empty tag; otherwise, XSAVE, XSAVEOPT, XSAVEC, and XSAVES save a 1 into bit 7 of 
byte 4. 


— Foreachj, 0 <j <7, XRSTOR and XRSTORS establish the tag value for x87 FPU data register STj as follows. 
If bit j of byte 4 is 0, the tag for STj in the tag register for that data register is marked empty (11B); 
otherwise, the x87 FPU sets the tag for STj based on the value being loaded into that register (see below). 


° Bytes 15:8 are used as follows: 
— If the instruction has no REX prefix, or if REX.W = 0: 
¢ Bytes 11:8 are used for bits 31:0 of the x87 FPU Instruction Pointer Offset (FIP). 


¢ If CPUID.(EAX=07H,ECX=0H):EBX[bit 13] = 0, bytes 13:12 are used for x87 FPU Instruction Pointer 
Selector (FCS). Otherwise, XSAVE, XSAVEOPT, XSAVEC, and XSAVES save these bytes as 0000H, and 
XRSTOR and XRSTORS ignore them. 


¢ Bytes 15:14 are not used. 
— If the instruction has a REX prefix with REX.W = 1, bytes 15:8 are used for the full 64 bits of FIP. 
° Bytes 23:16 are used as follows: 
— If the instruction has no REX prefix, or if REX.W = 0: 
¢ Bytes 19:16 are used for bits 31:0 of the x87 FPU Data Pointer Offset (FDP). 
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¢ If CPUID.(EAX=07H,ECX=0H):EBX[bit 13] = 0, bytes 21:20 are used for x87 FPU Data Pointer Selector 
(FDS). Otherwise, XSAVE, XSAVEOPT, XSAVEC, and XSAVES save these bytes as 0O00H; and XRSTOR 
and XRSTORS ignore them. 


¢ Bytes 23:22 are not used. 
— If the instruction has a REX prefix with REX.W = 1, bytes 23:16 are used for the full 64 bits of FDP. 
¢ Bytes 31:24 are used for SSE state (see Section 13.5.2). 


° Bytes 159:32 are used for the registers STO-ST7 (MMO-MM7). Each of the 8 register is allocated a 128-bit 
region, with the low 80 bits used for the register and the upper 48 bits unused. 


x87 state is XSAVE-managed but the x87 FPU feature is not XSAVE-enabled. The XSAVE feature set can operate on 
x87 state only if the feature set is enabled (CR4.OSXSAVE = 1).! Software can otherwise use x87 state even if the 
XSAVE feature set is not enabled. 


13.5.2 SSE State 


Instructions in the XSAVE feature set can manage the registers used by the streaming SIMD extensions (SSE 
state) just as the FXSAVE and FXRSTOR instructions do. They organize all SSE state as a user state component in 
the legacy region of the XSAVE area (see Section 13.4.1). This region is illustrated in Table 13-1; the SSE state is 
listed below, along with details of its interactions with the XSAVE feature set: 


° Bytes 23:0 are used for x87 state (see Section 13.5.1). 


° Bytes 27:24 are used for the MXCSR register. XRSTOR and XRSTORS generate general-protection faults (#GP) 
in response to attempts to set any of the reserved bits of the MXCSR register. 


¢ Bytes 31:28 are used for the MKCSR_MASK value. XRSTOR and XRSTORS ignore this field. 
¢ Bytes 159:32 are used for x87 state. 
¢ Bytes 287:160 are used for the registers XMMO-XMM7. 


¢ Bytes 415:288 are used for the registers XMM8-XMM15. These fields are used only in 64-bit mode. Executions 
of XSAVE, XSAVEOPT, XSAVEC, and XSAVES outside 64-bit mode do not modify these bytes; executions of 
XRSTOR and XRSTORS outside 64-bit mode do not update XMM8-XMM15. See Section 13.13. 


SSE state is XSAVE-managed but the SSE feature is not XSAVE-enabled. The XSAVE feature set can operate on SSE 
state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to manage SSE state 
(XCRO[1] = 1). Software can otherwise use SSE state even if the XSAVE feature set is not enabled or has not been 
configured to manage SSE state. 


13.5.3. AVX State 


The register state used by the Intel® Advanced Vector Extensions (AVX) comprises the MXCSR register and 16 256- 
bit vector registers called YMMO-YMM15. The low 128 bits of each register YMMi is identical to the SSE register 
XMMi. Thus, the new state register state added by AVX comprises the upper 128 bits of the registers YMMO- 
YMM15. These 16 128-bit values are denoted YMMO_H-YMM15_H and are collectively called AVX state. 


As noted in Section 13.1, the XSAVE feature set manages AVX state as user state component 2. Thus, AVX state is 
located in the extended region of the XSAVE area (see Section 13.4.3). 


As noted in Section 13.2, CPUID.(EAX=0DH,ECX=2):EBX enumerates the offset (in bytes, from the base of the 
XSAVE area) of the section of the extended region of the XSAVE area used for AVX state (when the standard format 
of the extended region is used). CPUID.(EAX=0DH,ECX=2):EAX enumerates the size (in bytes) required for AVX 
state. 


The XSAVE feature set partitions YMMO_H-YMM15_H in a manner similar to that used for the XMM registers (see 
Section 13.5.2). Bytes 127:0 of the AVX-state section are used for YMMO_H-YMM7_H. Bytes 255:128 are used for 


1. The processor ensures that XCRO[O] is always 1. 


2. While MXCSR and MXCSR_MASK are part of SSE state, their treatment by the XSAVE feature set is not the same as that of the XMM 
registers. See Section 13.7 through Section 13.11 for details. 
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YMM8_H-YMM15_H, but they are used only in 64-bit mode. Executions of XSAVE, XSAVEOPT, XSAVEC, and 
XSAVES outside 64-bit mode do not modify bytes 255:128; executions of XRSTOR and XRSTORS outside 64-bit 
mode do not update YMM8_H-YMM15_H. See Section 13.13. In general, bytes 16/+15:16/ are used for YMMi_H 
(forO0 </<15). 


AVX state is XSAVE-managed and the AVX feature is XSAVE-enabled. The XSAVE feature set can operate on AVX 
state only if the feature set is enabled (CR4.O0SXSAVE = 1) and has been configured to manage AVX state 
(XCRO[2] = 1). AVX instructions cannot be used unless the XSAVE feature set is enabled and has been configured 
to manage AVX state. 


13.5.4 MPX State 


The register state used by the Intel® Memory Protection Extensions (MPX) comprises the 4 128-bit bounds regis- 
ters BNDO-BND3 (BNDREGS state); and the 64-bit user-mode configuration register BNDCFGU and the 64-bit 
MPX status register BNDSTATUS (collectively, BNDCSR state). Together, these two user state components 
compose MPxX state. 


As noted in Section 13.1, the XSAVE feature set manages MPX state as state components 3-4. Thus, MPX state is 
located in the extended region of the XSAVE area (see Section 13.4.3). The following items detail how these state 
components are organized in this region: 


¢ BNDREGS state. 
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=3):EBX enumerates the offset (in bytes, from the base of the 
XSAVE area) of the section of the extended region of the XSAVE area used for BNDREGS state (when the 
standard format of the extended region is used). CPUID.(EAX=0DH,ECX=3):EAX enumerates the size (in 
bytes) required for BNDREGS state. The BNDREGS section is used for the 4 128-bit bound registers BNDO- 
BND3, with bytes 16/+15:16/ being used for BNDi. 

° BNDCSR state. 
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=4):EBX enumerates the offset of the section of the extended 
region of the XSAVE area used for BNDCSR state (when the standard format of the extended region is used). 
CPUID.(EAX=0DH,ECX=4):EAX enumerates the size (in bytes) required for BNDCSR state. In the BNDSCR 
section, bytes 7:0 are used for BNDCFGU and bytes 15:8 are used for BNDSTATUS. 


Both components of MPX state are XSAVE-managed and the MPX feature is XSAVE-enabled. The XSAVE feature set 
can operate on MPX state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to manage 
MPX state (XCRO[4:3] = 11b). MPX instructions cannot be used unless the XSAVE feature set is enabled and has 
been configured to manage MPxX state. 


13.5.5  AVX-512 State 


The register state used by the Intel® Advanced Vector Extensions 512 (AVX-512) comprises the MXCSR register, 
the 8 64-bit opmask registers kO-k7, and 32 512-bit vector registers called ZMMO-ZMM31. For each i, 0 <=i <= 
15, the low 256 bits of register ZMMi is identical to the AVX register YMM/. Thus, the new state register state added 
by AVX comprises the following user state components: 

¢ The opmask registers, collectively called opmask state. 


¢ The upper 256 bits of the registers ZMMO-ZMM15. These 16 256-bit values are denoted ZMMO_H-ZMM15_H 
and are collectively called ZMM_Hi256 state. 


° The 16 512-bit registers ZMM16-ZMM31, collectively called Hi16_ZMM state. 
Together, these three state components compose AVX-512 state. 


As noted in Section 13.1, the XSAVE feature set manages AVX-512 state as state components 5-7. Thus, AVX-512 
state is located in the extended region of the XSAVE area (see Section 13.4.3). The following items detail how 
these state components are organized in this region: 


° Opmask state. 
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=5):EBX enumerates the offset (in bytes, from the base of the 
XSAVE area) of the section of the extended region of the XSAVE area used for opmask state (when the standard 
format of the extended region is used). CPUID.(EAX=0DH,ECX=5):EAX enumerates the size (in bytes) 
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required for opmask state. The opmask section is used for the 8 64-bit opmask registers kO-k7, with 
bytes 8/+7:8/ being used for ki. 


* ZMM_Hi256 state. 
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=6):EBX enumerates the offset of the section of the extended 
region of the XSAVE area used for ZMM_Hi256 state (when the standard format of the extended region is 
used). CPUID.(EAX=0DH,ECX=6):EAX enumerates the size (in bytes) required for ZMM_Hi256 state. 


The XSAVE feature set partitions ZMMO_H-ZMM15_H in a manner similar to that used for the XMM registers 
(see Section 13.5.2). Bytes 255:0 of the ZMM_Hi256-state section are used for ZMMO_H-ZMM7_H. 

Bytes 511:256 are used for ZMM8_H-ZMM15_H, but they are used only in 64-bit mode. Executions of XSAVE, 
XSAVEOPT, XSAVEC, and XSAVES outside 64-bit mode do not modify bytes 511:256; executions of XRSTOR 
and XRSTORS outside 64-bit mode do not update ZMM8_H-ZMM15_H. See Section 13.13. In general, 

bytes 32/+31:32/ are used for ZMMi_H (for 0 <i< 15). 


¢ Hi16_ZMM state. 
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=7):EBX enumerates the offset of the section of the extended 
region of the XSAVE area used for Hi16_ZMM state (when the standard format of the extended region is used). 
CPUID.(EAX=0DH,ECX=7):EAX enumerates the size (in bytes) required for Hi16_ZMM state. 


The XSAVE feature set accesses Hi16_ZMM state only in 64-bit mode. Executions of XSAVE, XSAVEOPT, 
XSAVEC, and XSAVES outside 64-bit mode do not modify the Hil16_ZMM section; executions of XRSTOR and 
XRSTORS outside 64-bit mode do not update ZMM16-ZMM31. See Section 13.13. In general, 

bytes 64(ij-16)+63:64(/-16) are used for ZMMi (for 16 <i < 31). 


All three components of AVX-512 state are XSAVE-managed and the AVX-512 feature is XSAVE-enabled. The 
XSAVE feature set can operate on AVX-512 state only if the feature set is enabled (CR4.OSXSAVE = 1) and has 
been configured to manage AVX-512 state (XCRO[7:5] = 111b). AVX-512 instructions cannot be used unless the 
XSAVE feature set is enabled and has been configured to manage AVX-512 state. 


13.5.6 PT State 


The register state used by Intel Processor Trace (PT state) comprises the following 9 MSRs: IA32_RTIT_CTL, 
IA32_RTIT_OUTPUT_BASE, IA32_RTIT_OUTPUT_MASK_PTRS, IA32_RTIT_STATUS, IA32_RTIT_CR3_MATCH, 
IA32_RTIT_ADDRO_A, IA32_RTIT_ADDRO_B, IA32_RTIT_ADDR1_A, and IA32_RTIT_ADDR1_B.! 


As noted in Section 13.1, the XSAVE feature set manages PT state as supervisor state component 8. Thus, PT state 
is located in the extended region of the XSAVE area (see Section 13.4.3). As noted in Section 13.2, 
CPUID.(EAX=0DH,ECX=8):EAX enumerates the size (in bytes) required for PT state. The MSRs are each allocated 
8 bytes in the state component in the order given above. Thus, IA32_RTIT_CTL is at byte offset 0, 
IA32_RTIT_OUTPUT_BASE at byte offset 8, etc. Any locations in the state component at or beyond byte offset 72 
are reserved. 


PT state is XSAVE-managed but Intel Processor Trace is not XSAVE-enabled. The XSAVE feature set can operate on 
PT state only if the feature set is enabled (CR4.0SXSAVE = 1) and has been configured to manage PT state 
(IA32_XSS[8] = 1). Software can otherwise use Intel Processor Trace and access its MSRs (using RDMSR and 
WRMSR) even if the XSAVE feature set is not enabled or has not been configured to manage PT state. 


The following items describe special treatment of PT state by the XSAVES and XRSTORS instructions: 


¢ If XSAVES saves PT state, the instruction clears IA32_RTIT_CTL.TraceEn (bit 0) after saving the value of the 
IA32_RTIT_CTL MSR and before saving any other PT state. If XSAVES causes a fault or a VM exit, it restores 
IA32_RTIT_CTL.TraceEn to its original value. 


° If XSAVES saves PT state, the instruction saves zeroes in the reserved portions of the state component. 


¢ If XRSTORS would restore (or initialize) PT state and IA32_RTIT_CTL.TraceEn = 1, the instruction causes a 
general-protection exception (#GP) before modifying PT state. 


¢ If XRSTORS causes an exception or a VM exit, it does so before any modification to IA32_RTIT_CTL.TraceEn 
(even if it has loaded other PT state). 


1. These MSRs might not be supported by every processor that supports Intel Processor Trace. Software can use the CPUID instruction 
to discover which are supported; see Section 31.3.1, “Detection of Intel Processor Trace and Capability Enumeration,” of Intel® 64 
and IA-32 Architectures Software Developer's Manual, Volume 3C. 
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13.5.7. PKRU State 


The register state used by the protection-key feature (PKRU state) is the 32-bit PKRU register. As noted in Section 
13.1, the XSAVE feature set manages PKRU state as user state component 9. Thus, PKRU state is located in the 
extended region of the XSAVE area (see Section 13.4.3). 


As noted in Section 13.2, CPUID.(EAX=0DH,ECX=9):EBX enumerates the offset (in bytes, from the base of the 
XSAVE area) of the section of the extended region of the XSAVE area used for PKRU state (when the standard 
format of the extended region is used). CPUID.(EAX=0DH,ECX=9):EAX enumerates the size (in bytes) required for 
PKRU state. The XSAVE feature set uses bytes 3:0 of the PK-state section for the PKRU register. 


PKRU state is XSAVE-managed but the protection-key feature is not XSAVE-enabled. The XSAVE feature set can 
operate on PKRU state only if the feature set is enabled (CR4.OSXSAVE = 1) and has been configured to manage 
PKRU state (XCRO[9] = 1). Software can otherwise use protection keys and access PKRU state even if the XSAVE 
feature set is not enabled or has not been configured to manage PKRU state. 


The value of the PKRU register determines the access rights for user-mode linear addresses. (See Section 4.6, 
“Access Rights,” of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A.) The access rights 
that pertain to an execution of the XRSTOR and XRSTORS instructions are determined by the value of the register 
before the execution and not by any value that the execution might load into the PKRU register. 


13.5.8 CET State 


The register state used by Control-Flow Enforcement Technology (CET) comprises the two 64-bit MSRs 
(IA32_U_CET and IA32_PL3_SSP) that manage CET when CPL = 3 (CET_U state); and the three 64-bit MSRs 
(IA32_PLO_SSP-IA32_PL2_SSP) that manage CET when CPL < 3 (CET_S state). Together, these two user state 
components compose CET state. ! 


As noted in Section 13.1, the XSAVE feature set manages CET state as supervisor state components 11-23. Thus, 
CET state is located in the extended region of the XSAVE area (see Section 13.4.3). The following items detail how 
these state components are organized in this region: 


° CET_U state. 
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=11):EAX enumerates the size (in bytes) required for CET_U 
state. The CET_U section is used for the 64-bit MSRs IA32_U_CET and IA32_PL3_SSP, with bytes 7:0 being 
used for IA32_U_CET and bytes 15:8 being used for IA32_PL3_SSP. 


° CET_S state. 
As noted in Section 13.2, CPUID.(EAX=0DH,ECX=12):EAX enumerates the size (in bytes) required for CET_S 
state. The CET_S section is used for the three 64-bit MSRs IA32_PLO_SSP-IA32_PL2_SSP, with bytes 8/+7:8/ 
being used for IA32_PLi_SSP. 


The two components of CET state are XSAVE-managed and CET is not XSAVE-enabled. The XSAVE feature set can 
operate on CET_U state (respectively, CET_S state) only if the feature set is enabled (CR4.OSXSAVE = 1) and has 
been configured to manage CET_U state (respectively, CET_S state) by setting IA32_XSS[11] (respectively, 
IA32_XSS[12]). Software can otherwise use CET and access the CET MSRs (using RDMSR and WRMSR) even if the 
XSAVE feature set is not enabled or has not been configured to manage CET state. 


13.5.9 HDC State 


The register state used by hardware duty cycling (HDC state) comprises the IA32_PM_CTL1 MSR. 


As noted in Section 13.1, the XSAVE feature set manages HDC state as supervisor state component 13. Thus, HDC 
state is located in the extended region of the XSAVE area (see Section 13.4.3). As noted in Section 13.2, 
CPUID.(EAX=0DH,ECX=13):EAX enumerates the size (in bytes) required for HDC state. The IA32_PM_CTL1 MSR 
is allocated 8 bytes at byte offset 0 in the state component. 


HDC state is XSAVE-managed but hardware duty cycling is not XSAVE-enabled. The XSAVE feature set can operate 
on HDC state only if the feature set is enabled (CR4.0SXSAVE = 1) and has been configured to manage HDC state 


1. The lA32_S_ CET and lA32_INTERRUPT_SSP_TABLE_ADDR MSRs also control CET when CPL < 3. However, they are not managed by 
the XSAVE feature set and are thus not considered in this chapter. 
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(IA32_XSS[13] = 1). Software can otherwise use hardware duty cycling and access the IA32_PM_CTL1 MSR (using 
RDMSR and WRMSR) even if the XSAVE feature set is not enabled or has not been configured to manage HDC state. 


13.5.10 HWP State 
The register state used by hardware P-states (HWP state) comprises the IA32_HWP_REQUEST MSR. 


As noted in Section 13.1, the XSAVE feature set manages HWP state as supervisor state component 16. Thus, HWP 
state is located in the extended region of the XSAVE area (see Section 13.4.3). As noted in Section 13.2, 
CPUID.(EAX=0DH,ECX=16):EAX enumerates the size (in bytes) required for HWP state. The IA32_HWP_REQUEST 
MSR is allocated 8 bytes at byte offset 0 in the state component. 


HWP state is XSAVE-managed but the hardware P-states feature is not XSAVE-enabled. The XSAVE feature set can 
operate on HWP state only if the feature set is enabled (CR4.0OSXSAVE = 1) and has been configured to manage 
HWP state (IA32_XSS[16] = 1). Software can otherwise use hardware P-states and access the 
IA32_HWP_REQUEST MSR (using RDMSR and WRMSR) even if the XSAVE feature set is not enabled or has not 
been configured to manage HWP state. 


13.6 PROCESSOR TRACKING OF XSAVE-MANAGED STATE 


The XSAVEOPT, XSAVEC, and XSAVES instructions use two optimizations to reduce the amount of data that they 
write to memory. They avoid writing data for any state component known to be in its initial configuration (the init 
optimization). In addition, if either XSAVEOPT or XSAVES is using the same XSAVE area as that used by the most 
recent execution of XRSTOR or XRSTORS, it may avoid writing data for any state component whose configuration 
is known not to have been modified since then (the modified optimization). (XSAVE does not use these optimi- 
zations, and XSAVEC does not use the modified optimization.) The operation of XSAVEOPT, XSAVEC, and XSAVES 
are described in more detail in Section 13.9 through Section 13.11. 


A processor can support the init and modified optimizations with special hardware that tracks the state components 
that might benefit from those optimizations. Other implementations might not include such hardware; such a 
processor would always consider each such state component as not in its initial configuration and as modified since 
the last execution of XRSTOR or XRSTORS. 


The following notation describes the state of the init and modified optimizations: 


¢ XINUSE denotes the state-component bitmap corresponding to the init optimization. If XINUSE[/] = 0, state 
component / is known to be in its initial configuration; otherwise XINUSE[/] = 1. It is possible for XINUSE[/] to 
be 1 even when state component / is in its initial configuration. On a processor that does not support the init 
optimization, XINUSE[/] is always 1 for every value of i. 


Executing XGETBV with ECX = 1 returns in EDX:EAX the logical-AND of XCRO and the current value of the 
XINUSE state-component bitmap. Such an execution of XGETBV always sets EAX[1] to 1 if XCRO[1] = 1 and 
MXCSR does not have its RESET value of 1F80H. Section 13.2 explains how software can determine whether a 
processor supports this use of XGETBV. 


¢ XMODIFIED denotes the state-component bitmap corresponding to the modified optimization. If 
XMODIFIED[/] = 0, state component / is known not to have been modified since the most recent execution of 
XRSTOR or XRSTORS; otherwise XMODIFIED[/] = 1. It is possible for XMODIFIED[/] to be 1 even when state 
component / has not been modified since the most recent execution of XRSTOR or XRSTORS. On a processor 
that does not support the modified optimization, XMODIFIED[/] is always 1 for every value of i. 


A processor that implements the modified optimization saves information about the most recent execution of 
XRSTOR or XRSTORS in a quantity called XRSTOR_INFO, a 4-tuple containing the following: (1) the CPL; 

(2) whether the logical processor was in VMX non-root operation; (3) the linear address of the XSAVE area; and 
(4) the XCOMP_BV field in the XSAVE area. An execution of XSAVEOPT or XSAVES uses the modified optimization 
only if that execution corresponds to XRSTOR_INFO on these four parameters. 


This mechanism implies that, depending on details of the operating system, the processor might determine that an 
execution of XSAVEOPT by one user application corresponds to an earlier execution of XRSTOR by a different appli- 
cation. For this reason, Intel recommends the application software not use the XSAVEOPT instruction. 
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The following items specify the initial configuration each state component (for the purposes of defining the XINUSE 
bitmap): 


° x87 state. x87 state is in its initial configuration if the following all hold: FCW is 037FH; FSW is OOOOH; FTW is 
FFFFH; FCS and FDS are each OOOOH; FIP and FDP are each 00000000_00000000H; each of STO-ST7 is 
0000_00000000_00000000H. 


° SSE state. In 64-bit mode, SSE state is in its initial configuration if each of XMMO-XMM15 is 0. Outside 64-bit 
mode, SSE state is in its initial configuration if each of XMMO-XMM7 is 0. XINUSE[1] pertains only to the state 
of the XMM registers and not to MXCSR. An execution of XRSTOR or XRSTORS outside 64-bit mode does not 
update XMM8-XMM15. (See Section 13.13.) 


° AVX state. In 64-bit mode, AVX state is in its initial configuration if each of YMMO_H-YMM15_H is 0. Outside 
64-bit mode, AVX state is in its initial configuration if each of YMMO_H-YMM7_H is 0. An execution of XRSTOR 
or XRSTORS outside 64-bit mode does not update YMM8_H-YMM15_H. (See Section 13.13.) 


¢ BNDREGS state. BNDREGS state is in its initial configuration if the value of each of BNDO-BND3 is 0. 
° BNDCSR state. BNDCSR state is in its initial configuration if BNDCFGU and BNDCSR each has value 0. 
¢ Opmask state. Opmask state is in its initial configuration if each of the opmask registers kO-k7 is 0. 


° ZMM_Hi256 state. In 64-bit mode, ZMM_Hi256 state is in its initial configuration if each of ZMMO_H- 
ZMM15_H is 0. Outside 64-bit mode, ZMM_Hi256 state is in its initial configuration if each of ZMMO_H-ZMM7_H 
is 0. An execution of XRSTOR or XRSTORS outside 64-bit mode does not update ZMM8_H-ZMM15_H. (See 
Section 13.13.) 


° Hi16_ZMM state. In 64-bit mode, Hi16_ZMM state is in its initial configuration if each of ZMM16-—ZMM31 is 0. 
Outside 64-bit mode, Hi16_ZMM state is always in its initial configuration. An execution of XRSTOR or XRSTORS 
outside 64-bit mode does not update ZMM31-ZMM31. (See Section 13.13.) 


¢ PT state. PT state is in its initial configuration if each of the 9 MSRs is 0. 

¢ PKRU state. PKRU state is in its initial configuration if the value of the PKRU is 0. 

¢ PT state. PT state is in its initial configuration if each of the 9 MSRs is 0. 

¢ CET_U state. CET_U state is in its initial configuration if both of the MSRs are 0. 

° CET_S state. CET_S state is in its initial configuration if each of the three MSRs is 0. 

° HDC state. HDC state is in its initial configuration if the value of the IA32_PM_CTL1 MSR is 1. 

¢ HWP state. HWP state is in its initial configuration if the value of the IA32_HWP_REQUEST MSR is 8000FFO1H. 


13.7. OPERATION OF XSAVE 


The XSAVE instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair 
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction 
mask. The logical-AND of XCRO and the instruction mask is the requested-feature bitmap (RFBM) of the user 
state components to be saved. 


The following conditions cause execution of the XSAVE instruction to generate a fault: 
e If the XSAVE feature set is not enabled (CR4.OSXSAVE = 0), an invalid-opcode exception (#UD) occurs. 
° If CRO.TS[bit 3] is 1, a device-not-available exception (#NM) occurs. 

e If the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP) occurs. 


If none of these conditions cause a fault, execution of XSAVE reads the XSTATE_BV field of the XSAVE header (see 

Section 13.4.2) and writes it back to memory, setting XSTATE_BV[/] (0 <i < 63) as follows: 

° If RFBM[/] = 0, XSTATE_BV[/] is not changed. 

° If RFBM[/] = 1, XSTATE_BV[/] is set to the value of XINUSE[/]. Section 13.6 defines XINUSE to describe the 
processor init optimization and specifies the initial configuration of each state component. The nature of that 
optimization implies the following: 


1 


1. If CRO.AM = 1, CPL = 3, and EFLAGS.AC =1, an alignment-check exception (HAC) may occur instead of #GP. 
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— If state component /is in its initial configuration, XINUSE[/] may be either 0 or 1, and XSTATE_BV[/] may be 
written with either 0 or 1. 


XINUSE[1] pertains only to the state of the XMM registers and not to MXCSR. Thus, XSTATE_BV[1] may be 
written with 0 even if MXCSR does not have its RESET value of 1F80H. 


— If state component / is not in its initial configuration, XINUSE[/] = 1 and XSTATE_BV[/] is written with 1. 


(As explained in Section 13.6, the initial configurations of some state components may depend on whether the 
processor is in 64-bit mode.) 


The XSAVE instruction does not write any part of the XSAVE header other than the XSTATE_BV field; in particular, 
it does not write to the XCOMP_BV field. 


Execution of XSAVE saves into the XSAVE area those state components corresponding to bits that are set in RFBM. 
State components 0 and 1 are located in the legacy region of the XSAVE area (see Section 13.4.1). Each state 
component /, 2 <i < 62, is located in the extended region; the XSAVE instruction always uses the standard format 
for the extended region (see Section 13.4.3). 


The MXCSR register and MKCSR_MASK are part of SSE state (see Section 13.5.2) and are thus associated with 
RFBM[1]. However, the XSAVE instruction also saves these values when RFBM[2] = 1 (even if RFBM[1] = 0). 


See Section 13.5 for specifics for each state component and for details regarding mode-specific operation and 
operation determined by instruction prefixes. See Section 13.13 for details regarding faults caused by memory 
accesses. 


13.8 OPERATION OF XRSTOR 


The XRSTOR instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair 
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction 
mask. The logical-AND of XCRO and the instruction mask is the requested-feature bitmap (RFBM) of the user 
state components to be restored. 


The following conditions cause execution of the XRSTOR instruction to generate a fault: 

e If the XSAVE feature set is not enabled (CR4.OSXSAVE = 0), an invalid-opcode exception (#UD) occurs. 
¢ If CRO.TS[bit 3] is 1, a device-not-available exception (#NM) occurs. 

* If the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP) occurs.! 


After checking for these faults, the XRSTOR instruction reads the XCOMP_BV field in the XSAVE area’s XSAVE 
header (see Section 13.4.2). If XCOMP_BV[63] = 0, the standard form of XRSTOR is executed (see Section 
13.8.1); otherwise, the compacted form of XRSTOR is executed (see Section 13.8.2). 


See Section 13.2 for details of how to determine whether the compacted form of XRSTOR is supported. 


13.8.1 Standard Form of XRSTOR 


The standard from of XRSTOR performs additional fault checking. Either of the following conditions causes a 
general-protection exception (#GP): 


¢ The XSTATE_BV field of the XSAVE header sets a bit that is not set in XCRO. 
* Bytes 23:8 of the XSAVE header are not all 0 (this implies that all bits in XCOMP_BV are 0). 


1. If CRO.AM = 1, CPL = 3, and EFLAGS.AC =1, an alignment-check exception (HAC) may occur instead of #GP. 


2. If the processor does not support the compacted form of XRSTOR, it may execute the standard form of XRSTOR without first read- 
ing the XCOMP_BV field. A processor supports the compacted form of XRSTOR only if it enumerates 
CPUID.(EAX=0DH,ECX=1):EAX[1] as 1. 

3. Bytes 63:24 of the XSAVE header are also reserved. Software should ensure that bytes 63:16 of the XSAVE header are all O in any 
XSAVE area. (Bytes 15:8 should also be 0 if the XSAVE area is to be used on a processor that does not support the compaction 
extensions to the XSAVE feature set.) 
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If none of these conditions cause a fault, the processor updates each state component / for which RFBM[/] = 1. 

XRSTOR updates state component ij based on the value of bit / in the XSTATE_BV field of the XSAVE header: 

° If XSTATE_BV[/] = 0, the state component is set to its initial configuration. Section 13.6 specifies the initial 
configuration of each state component. 
The initial configuration of state component 1 pertains only to the XMM registers and not to MXCSR. See below 
for the treatment of MKCSR 

° If XSTATE_BV[/] = 1, the state component is loaded with data from the XSAVE area. See Section 13.5 for 
specifics for each state component and for details regarding mode-specific operation and operation determined 
by instruction prefixes. See Section 13.13 for details regarding faults caused by memory accesses. 
State components 0 and 1 are located in the legacy region of the XSAVE area (see Section 13.4.1). Each state 


component /, 2 <i < 62, is located in the extended region; the standard form of XRSTOR uses the standard 
format for the extended region (see Section 13.4.3). 


The MXCSR register is part of state component 1, SSE state (see Section 13.5.2). However, the standard form of 
XRSTOR loads the MXCSR register from memory whenever the RFBM[1] (SSE) or RFBM[2] (AVX) is set, regardless 
of the values of XSTATE_BV[1] and XSTATE_BV[2]. The standard form of XRSTOR causes a general-protection 
exception (#GP) if it would load MXCSR with an illegal value. 


13.8.2 |Compacted Form of XRSTOR 


The compacted from of XRSTOR performs additional fault checking. Any of the following conditions causes a #GP: 
° The XCOMP_BV field of the XSAVE header sets a bit in the range 62:0 that is not set in XCRO. 

¢ The XSTATE_BV field of the XSAVE header sets a bit (including bit 63) that is not set in XCOMP_BV. 

° Bytes 63:16 of the XSAVE header are not all 0. 


If none of these conditions cause a fault, the processor updates each state component / for which RFBM[/] = 1. 
XRSTOR updates state component ij based on the value of bit / in the XSTATE_BV field of the XSAVE header: 


° If XSTATE_BV[/] = 0, the state component is set to its initial configuration. Section 13.6 specifies the initial 
configuration of each state component. 

If XSTATE_BV[1] = 0, the compacted form XRSTOR initializes MXCSR to 1F80H. (This differs from the standard 
from of XRSTOR, which loads MXCSR from the XSAVE area whenever either RFBM[1] or RFBM[2] is set.) 
State component / is set to its initial configuration as indicated above if RFBM[/] = 1 and XSTATE_BV[/] = 0 — 
even if XCOMP_BV[i] = 0. This is true for all values of i, including 0 (x87 state) and 1 (SSE state). 

° If XSTATE_BV[/] = 1, the state component is loaded with data from the XSAVE area.! See Section 13.5 for 
specifics for each state component and for details regarding mode-specific operation and operation determined 
by instruction prefixes. See Section 13.13 for details regarding faults caused by memory accesses. 

State components 0 and 1 are located in the legacy region of the XSAVE area (see Section 13.4.1). Each state 
component /, 2 <i < 62, is located in the extended region; the compacted form of the XRSTOR instruction uses 
the compacted format for the extended region (see Section 13.4.3). 


The MXCSR register is part of SSE state (see Section 13.5.2) and is thus loaded from memory if RFBM[1] = 
XSTATE_BV[/] = 1. The compacted form of XRSTOR does not consider RFBM[2] (AVX) when determining whether 
to update MXCSR. (This is a difference from the standard form of XRSTOR.) The compacted form of XRSTOR causes 
a general-protection exception (#GP) if it would load MXCSR with an illegal value. 


13.8.3. XRSTOR and the Init and Modified Optimizations 


Execution of the XRSTOR instruction causes the processor to update its tracking for the init and modified optimiza- 
tions (see Section 13.6). The following items provide details: 


¢ The processor updates its tracking for the init optimization as follows: 


1. Earlier fault checking ensured that, if the instruction has reached this point in execution and XSTATE_BV[i] is 1, then XCOMP_BV[i] is 
also 1. 
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— If RFBM[/] = 0, XINUSE[/] is not changed. 


— If RFBM[/] = 1 and XSTATE_BV[/] = 0, state component / may be tracked as init; XINUSE[/] may be set to 
0 or 1. (As noted in Section 13.6, a processor need not implement the init optimization for state component 
i; a processor that does not do so implicitly maintains XINUSE[/] = 1 at all times.) 


— If RFBM[/] = 1 and XSTATE_BV[/] = 1, state component i is tracked as not init; XINUSE[/] is set to 1. 


¢ The processor updates its tracking for the modified optimization and records information about the XRSTOR 
execution for future interaction with the XSAVEOPT and XSAVES instructions (see Section 13.9 and Section 
13.11) as follows: 


— If RFBM[/] = 0, state component j is tracked as modified; XMODIFIED[/] is set to 1. 


— If RFBM[/] = 1, state component ji may be tracked as unmodified; XMODIFIED[/] may be set to 0 or 1. (As 
noted in Section 13.6, a processor need not implement the modified optimization for state component /; a 
processor that does not do so implicitly maintains XMODIFIED[/] = 1 at all times.) 


— XRSTOR_INFO is set to the 4-tuple (w,x,y,z), where w is the CPL (0); x is 1 if the logical processor is in VMX 
non-root operation and 0 otherwise; y is the linear address of the XSAVE area; and z is XCOMP_BV. In 
particular, the standard form of XRSTOR always sets z to all zeroes, while the compacted form of XRSTORS 
never does so (because it sets at least bit 63 to 1). 


Note that, if RFBM is entirely zero (e.g., because the instruction mask in EDX:EAX is zero), no state components are 
modified, the XINUSE bitmap is not modified, and all bits are set in the XMODIFIED bitmap. Thus, if EDX:EAX was 
zero for the most recent execution of XRSTOR, an execution of XSAVEOPT or XSAVES will identify all state compo- 
nents as modified and will thus not use the modified optimization. 


13.9 OPERATION OF XSAVEOPT 


The operation of XSAVEOPT is similar to that of XSAVE. Unlike XSAVE, XSAVEOPT uses the init optimization (by 
which it may omit saving state components that are in their initial configuration) and the modified optimization (by 
which it may omit saving state components that have not been modified since the last execution of XRSTOR); see 
Section 13.6. See Section 13.2 for details of how to determine whether XSAVEOPT is supported. 


The XSAVEOPT instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair 
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction 
mask. The logical (bitwise) AND of XCRO and the instruction mask is the requested-feature bitmap (RFBM) of 
the user state components to be saved. 


The following conditions cause execution of the XSAVEOPT instruction to generate a fault: 

e If the XSAVE feature set is not enabled (CR4.OSXSAVE = 0), an invalid-opcode exception (#UD) occurs. 
¢ If CRO.TS[bit 3] is 1, a device-not-available exception (#NM) occurs. 

* If the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP) occurs.! 


If none of these conditions cause a fault, execution of XSAVEOPT reads the XSTATE_BV field of the XSAVE header 
(see Section 13.4.2) and writes it back to memory, setting XSTATE_BV[/] (0 <i < 63) as follows: 


e If RFBM[/] = 0, XSTATE_BV[/] is not changed. 


e If RFBM[/] = 1, XSTATE_BV[/] is set to the value of XINUSE[/]. Section 13.6 defines XINUSE to describe the 
processor init optimization and specifies the initial configuration of each state component. The nature of that 
optimization implies the following: 


— Ifthe state component is in its initial configuration, XINUSE[/] may be either 0 or 1, and XSTATE_BV[/] may 
be written with either 0 or 1. 


XINUSE[1] pertains only to the state of the XMM registers and not to MXCSR. Thus, XSTATE_BV[1] may be 
written with 0 even if MXCSR does not have its RESET value of 1F80H. 


— Ifthe state component is not in its initial configuration, XSTATE_BV[/] is written with 1. 


1. If CRO.AM = 1, CPL = 3, and EFLAGS.AC =1, an alignment-check exception (HAC) may occur instead of #GP. 
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(As explained in Section 13.6, the initial configurations of some state components may depend on whether the 
processor is in 64-bit mode.) 


The XSAVEOPT instruction does not write any part of the XSAVE header other than the XSTATE_BV field; in partic- 
ular, it does not write to the XCOMP_BV field. 


Execution of XSAVEOPT saves into the XSAVE area those state components corresponding to bits that are set in 
RFBM (subject to the optimizations described below). State components 0 and 1 are located in the legacy region of 
the XSAVE area (see Section 13.4.1). Each state component /, 2 <i < 62, is located in the extended region; the 
XSAVEOPT instruction always uses the standard format for the extended region (see Section 13.4.3). 


See Section 13.5 for specifics for each state component and for details regarding mode-specific operation and 
operation determined by instruction prefixes. See Section 13.13 for details regarding faults caused by memory 
accesses. 


Execution of XSAVEOPT performs two optimizations that reduce the amount of data written to memory: 

¢ Init optimization. 
If XINUSE[/] = 0, state component / is not saved to the XSAVE area (even if RFBM[/] = 1). (See below for 
exceptions made for MXCSR.) 

¢* Modified optimization. 
Each execution of XRSTOR and XRSTORS establishes XRSTOR_INFO as a 4-tuple (w,x,y,z) (see Section 13.8.3 


and Section 13.12). Execution of XSAVEOPT uses the modified optimization only if the following all hold for the 
current value of XRSTOR_INFO: 


— w=CPL; 
— x = 1 if and only if the logical processor is in VMX non-root operation; 
— yis the linear address of the XSAVE area being used by XSAVEOPT; and 


— zis 00000000_OO000000H. (This last item implies that XSAVEOPT does not use the modified optimization 
if the last execution of XRSTOR used the compacted form, or if an execution of XRSTORS followed the last 
execution of XRSTOR.) 


If XSAVEOPT uses the modified optimization and XMODIFIED[/] = 0 (see Section 13.6), state component / is 
not saved to the XSAVE area. 


(In practice, the benefit of the modified optimization for state component i depends on how the processor is 
tracking state component /; see Section 13.6. Limitations on the tracking ability may result in state component 
i being saved even though is in the same configuration that was loaded by the previous execution of XRSTOR.) 


Depending on details of the operating system, an execution of XSAVEOPT by a user application might use the 


modified optimization when the most recent execution of XRSTOR was by a different application. Because of 
this, Intel recommends the application software not use the XSAVEOPT instruction. 


The MXCSR register and MKXCSR_MASK are part of SSE state (see Section 13.5.2) and are thus associated with 
bit 1 of RFBM. However, the XSAVEOPT instruction also saves these values when RFBM[2] = 1 (even if RFBM[1] = 
0). The init and modified optimizations do not apply to the MXCSR register and MKCSR_MASK. 


13.10 OPERATION OF XSAVEC 


The operation of XSAVEC is similar to that of XSAVE. Two main differences are (1) XSAVEC uses the compacted 
format for the extended region of the XSAVE area; and (2) XSAVEC uses the init optimization (see Section 13.6). 
Unlike XSAVEOPT, XSAVEC does not use the modified optimization. See Section 13.2 for details of how to deter- 
mine whether XSAVEC is supported. 


The XSAVEC instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair 
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction 
mask. The logical (bitwise) AND of XCRO and the instruction mask is the requested-feature bitmap (RFBM) of 
the user state components to be saved. 


The following conditions cause execution of the XSAVEC instruction to generate a fault: 
e If the XSAVE feature set is not enabled (CR4.0SXSAVE = 0), an invalid-opcode exception (#UD) occurs. 
° If CRO.TS[bit 3] is 1, a device-not-available exception (#NM) occurs. 
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* If the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP) occurs.! 


If none of these conditions cause a fault, execution of XSAVEC writes the XSTATE_BV field of the XSAVE header 
(see Section 13.4.2), setting XSTATE_BV[/] (0 <i < 63) as follows: 


e If RFBM[/] = 0, XSTATE_BV[/] is written as 0. 


e If RFBM[/] = 1, XSTATE_BV[/] is set to the value of XINUSE[/] (see below for an exception made for 
XSTATE_BV[1]). Section 13.6 defines XINUSE to describe the processor init optimization and specifies the 
initial configuration of each state component. The nature of that optimization implies the following: 


— If state component / is in its initial configuration, XSTATE_BV[/] may be written with either 0 or 1. 
— If state component / is not in its initial configuration, XSTATE_BV[/] is written with 1. 


XINUSE[1] pertains only to the state of the XMM registers and not to MXCSR. However, if RFBM[1] = 1 and 
MXCSR does not have the value 1F80H, XSAVEC writes XSTATE_BV[1] as 1 even if XINUSE[1] = 0. 


(As explained in Section 13.6, the initial configurations of some state components may depend on whether the 
processor is in 64-bit mode.) 


The XSAVEC instructions sets bit 63 of the XCOMP_BV field of the XSAVE header while writing RFBM[62:0] to 
XCOMP_BV[62:0]. The XSAVEC instruction does not write any part of the XSAVE header other than the XSTATE_BV 
and XCOMP_BV fields. 


Execution of XSAVEC saves into the XSAVE area those state components corresponding to bits that are set in RFBM 
(subject to the init optimization described below). State components 0 and 1 are located in the legacy region of the 
XSAVE area (see Section 13.4.1). Each state component i, 2 <i < 62, is located in the extended region; the XSAVEC 
instruction always uses the compacted format for the extended region (see Section 13.4.3). 


See Section 13.5 for specifics for each state component and for details regarding mode-specific operation and 
operation determined by instruction prefixes. See Section 13.13 for details regarding faults caused by memory 
accesses. 


Execution of XSAVEC performs the init optimization to reduce the amount of data written to memory. If 
XINUSE[/] = 0, state component / is not saved to the XSAVE area (even if RFBM[/] = 1). However, if RFBM[1] = 1 
and MXCSR does not have the value 1F80H, XSAVEC saves all of state component 1 (SSE — including the XMM 
registers) even if XINUSE[1] = 0. Unlike the XSAVE instruction, RFBM[2] does not determine whether XSAVEC 
saves MXCSR and MXCSR_MASK. 


13.11 OPERATION OF XSAVES 


The operation of XSAVES is similar to that of XSAVEC. The main differences are (1) XSAVES can be executed only 
if CPL = 0; (2) XSAVES can operate on the state components whose bits are set in XCRO | IA32_XSS and can thus 
operate on supervisor state components; and (3) XSAVES uses the modified optimization (see Section 13.6). See 
Section 13.2 for details of how to determine whether XSAVES is supported. 


The XSAVES instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair 
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction 
mask. EDX:EAX & (XCRO | IA32_XSS) (the logical AND the instruction mask with the logical OR of XCRO and 
IA32_XSS) is the requested-feature bitmap (RFBM) of the state components to be saved. 


The following conditions cause execution of the XSAVES instruction to generate a fault: 
e If the XSAVE feature set is not enabled (CR4.OSXSAVE = 0), an invalid-opcode exception (#UD) occurs. 
° If CRO.TS[bit 3] is 1, a device-not-available exception (#NM) occurs. 


¢ If CPL > 0 or if the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP) 
occurs. 


If none of these conditions cause a fault, execution of XSAVES writes the XSTATE_BV field of the XSAVE header 
(see Section 13.4.2), setting XSTATE_BV[/] (0 <i < 63) as follows: 


1. If CRO.AM = 1, CPL = 3, and EFLAGS.AC =1, an alignment-check exception (HAC) may occur instead of #GP. 
2. Unlike the XSAVE and XSAVEOPT instructions, the XSAVEC instruction does not read the XSTATE_BV field of the XSAVE header. 
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¢ = If RFBM[/] = 0, XSTATE_BV[/] is written as 0. 
° If RFBM[/] = 1, XSTATE_BV[/] is set to the value of XINUSE[/] (see below for an exception made for 


XSTATE_BV[1]). Section 13.6 defines XINUSE to describe the processor init optimization and specifies the 
initial configuration of each state component. The nature of that optimization implies the following: 


— If state component / is in its initial configuration, XSTATE_BV[/] may be written with either 0 or 1. 
— If state component / is not in its initial configuration, XSTATE_BV[/] is written with 1. 


XINUSE[1] pertains only to the state of the XMM registers and not to MXCSR. However, if RFBM[1] = 1 and 
MXCSR does not have the value 1F80H, XSAVES writes XSTATE_BV[1] as 1 even if XINUSE[1] = 0. 


(As explained in Section 13.6, the initial configurations of some state components may depend on whether the 
processor is in 64-bit mode.) 


The XSAVES instructions sets bit 63 of the XCOMP_BV field of the XSAVE header while writing RFBM[62:0] to 
XCOMP_BV[62:0]. The XSAVES instruction does not write any part of the XSAVE header other than the XSTATE_BV 
and XCOMP_BV fields. 


Execution of XSAVES saves into the XSAVE area those state components corresponding to bits that are set in RFBM 
(subject to the optimizations described below). State components 0 and 1 are located in the legacy region of the 
XSAVE area (see Section 13.4.1). Each state component /, 2 <i < 62, is located in the extended region; the XSAVES 
instruction always uses the compacted format for the extended region (see Section 13.4.3). 


See Section 13.5 for specifics for each state component and for details regarding mode-specific operation and 
operation determined by instruction prefixes; in particular, see Section 13.5.6 for some special treatment of PT 
state by XSAVES. See Section 13.13 for details regarding faults caused by memory accesses. 


Execution of XSAVES performs the init optimization to reduce the amount of data written to memory. If 
XINUSE[/] = 0, state component / is not saved to the XSAVE area (even if RFBM[/] = 1). However, if RFBM[1] = 1 
and MXCSR does not have the value 1F80H, XSAVES saves all of state component 1 (SSE — including the XMM 
registers) even if XINUSE[1] = 0. 


Like XSAVEOPT, XSAVES may perform the modified optimization. Each execution of XRSTOR and XRSTORS estab- 
lishes XRSTOR_INFO as a 4-tuple (w,x,y,z) (see Section 13.8.3 and Section 13.12). Execution of XSAVES uses the 
modified optimization only if the following all hold: 


° w=CPL,; 
¢ x = 1 if and only if the logical processor is in VMX non-root operation; 
e yis the linear address of the XSAVE area being used by XSAVEOPT; and 


° z[63] is 1 and z[62:0] = RFBM[62:0]. (This last item implies that XSAVES does not use the modified optimi- 
zation if the last execution of XRSTOR used the standard form and followed the last execution of XRSTORS.) 


If XSAVES uses the modified optimization and XMODIFIED[/] = 0 (see Section 13.6), state component j is not 
saved to the XSAVE area. 


13.12 OPERATION OF XRSTORS 


The operation of XRSTORS is similar to that of XRSTOR. Three main differences are (1) XRSTORS can be executed 
only if CPL = 0; (2) XRSTORS can operate on the state components whose bits are set in XCRO | IA32_XSS and can 
thus operate on supervisor state components; and (3) XRSTORS has only a compacted form (no standard form; 
see Section 13.8). See Section 13.2 for details of how to determine whether XRSTORS is supported. 


The XRSTORS instruction takes a single memory operand, which is an XSAVE area. In addition, the register pair 
EDX:EAX is an implicit operand used as a state-component bitmap (see Section 13.1) called the instruction 
mask. EDX:EAX & (XCRO | IA32_XSS) (the logical AND the instruction mask with the logical OR of XCRO and 
IA32_XSS) is the requested-feature bitmap (RFBM) of the state components to be restored. 


The following conditions cause execution of the XRSTOR instruction to generate a fault: 
e If the XSAVE feature set is not enabled (CR4.OSXSAVE = 0), an invalid-opcode exception (#UD) occurs. 
¢ If CRO.TS[bit 3] is 1, a device-not-available exception (#NM) occurs. 
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¢ If CPL > 0 or if the address of the XSAVE area is not 64-byte aligned, a general-protection exception (#GP) 
occurs. 


After checking for these faults, the XRSTORS instruction reads the first 64 bytes of the XSAVE header, including the 
XSTATE_BV and XCOMP_BV fields (see Section 13.4.2). A #GP occurs if any of the following conditions hold for the 
values read: 

¢ XCOMP_BV[63] = 0. 

¢ XCOMP_BV sets a bit in the range 62:0 that is not set in XCRO | IA32_XSS. 

°  XSTATE_BV sets a bit (including bit 63) that is not set in XCOMP_BV. 

° Bytes 63:16 of the XSAVE header are not all 0. 


If none of these conditions cause a fault, the processor updates each state component / for which RFBM[/] = 1. 
XRSTORS updates state component ij based on the value of bit / in the XSTATE_BV field of the XSAVE header: 


¢ If XSTATE_BV[/] = 0, the state component is set to its initial configuration. Section 13.6 specifies the initial 
configuration of each state component. If XSTATE_BV[1] = 0, XRSTORS initializes MXCSR to 1F80H. 


State component / is set to its initial configuration as indicated above if RFBM[/] = 1 and XSTATE_BV[/] = 0 — 
even if XCOMP_BV[i] = 0. This is true for all values of /, including 0 (x87 state) and 1 (SSE state). 


° If XSTATE_BV[/] = 1, the state component is loaded with data from the XSAVE area.! See Section 13.5 for 
specifics for each state component and for details regarding mode-specific operation and operation determined 
by instruction prefixes; in particular, see Section 13.5.6 for some special treatment of PT state by XRSTORS. 
See Section 13.13 for details regarding faults caused by memory accesses. 


If XRSTORS is restoring a supervisor state component, the instruction causes a general-protection exception 
(#GP) if it would load any element of that component with an unsupported value (e.g., by setting a reserved bit 
in an MSR) or if a bit is set in any reserved portion of the state component in the XSAVE area. 


State components 0 and 1 are located in the legacy region of the XSAVE area (see Section 13.4.1). Each state 
component /, 2 <i < 62, is located in the extended region; XRSTORS uses the compacted format for the 
extended region (see Section 13.4.3). 


The MXCSR register is part of SSE state (see Section 13.5.2) and is thus loaded from memory if RFBM[1] = 
XSTATE_BV[/] = 1. XRSTORS causes a general-protection exception (#GP) if it would load MXCSR with an 
illegal value. 


If an execution of XRSTORS causes an exception or a VM exit during or after restoring a supervisor state compo- 

nent, each element of that state component may have the value it held before the XRSTORS execution, the value 
loaded from the XSAVE area, or the element’s initial value (as defined in Section 13.6). See Section 13.5.6 for some 
special treatment of PT state for the case in which XRSTORS causes an exception or a VM exit. 


Like XRSTOR, execution of XRSTORS causes the processor to update is tracking for the init and modified optimiza- 
tions (see Section 13.6 and Section 13.8.3). The following items provide details: 


¢ The processor updates its tracking for the init optimization as follows: 
— If RFBM[/] = 0, XINUSE[/] is not changed. 


— If RFBM[/] = 1 and XSTATE_BV[/] = 0, state component / may be tracked as init; XINUSE[/] may be set to 
Oorl. 


— If RFBM[/] = 1 and XSTATE_BV[/] = 1, state component i is tracked as not init; XINUSE[/] is set to 1. 


¢ The processor updates its tracking for the modified optimization and records information about the XRSTORS 
execution for future interaction with the XSAVEOPT and XSAVES instructions as follows: 


— If RFBM[/] = 0, state component j is tracked as modified; XMODIFIED[/] is set to 1. 
— If RFBM[/] = 1, state component / may be tracked as unmodified; XMODIFIED[/] may be set to 0 or 1. 


— XRSTOR_INFO is set to the 4-tuple (w,x,y,z), where w is the CPL; x is 1 if the logical processor is in VMX 
non-root operation and 0 otherwise; y is the linear address of the XSAVE area; and z is XCOMP_BV (this 
implies that z[63] = 1). 


1. Earlier fault checking ensured that, if the instruction has reached this point in execution and XSTATE_BV[i] is 1, then XCOMP_BV[]] is 
also 1. 
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Note that, if RFBM is entirely zero (e.g., because the instruction mask in EDX:EAX is zero), no state components 
are modified, the XINUSE bitmap is not modified, and all bits are set in the XMODIFIED bitmap. Thus, if EDX:EAX 
was zero for the most recent execution of XRSTORS, an execution of XSAVEOPT or XSAVES will identify all state 
components as modified and will thus not use the modified optimization. 


13.13. MEMORY ACCESSES BY THE XSAVE FEATURE SET 


Each instruction in the XSAVE feature set operates on a set of XSAVE-managed state components. The specific set 
of components on which an instruction operates is determined by the values of XCRO, the IA32_XSS MSR, 
EDX:EAX, and (for XRSTOR and XRSTORS) the XSAVE header. 


Section 13.4 provides the details necessary to determine the location of each state component for any execution of 
an instruction in the XSAVE feature set. An execution of an instruction in the XSAVE feature set may access any 
byte of any state component on which that execution operates. 


Section 13.5 provides details of the different XSAVE-managed state components. Some portions of some of these 
components are accessible only in 64-bit mode. Executions of XRSTOR and XRSTORS outside 64-bit mode will not 
update those portions; executions of XSAVE, XSAVEC, XSAVEOPT, and XSAVES will not modify the corresponding 
locations in memory. 


Despite this fact, any execution of these instructions outside 64-bit mode may access any byte in any state compo- 
nent on which that execution operates — even those at addresses corresponding to registers that are accessible 
only in 64-bit mode. As result, such an execution may incur a fault due to an attempt to access such an address. 


For example, an execution of XSAVE outside 64-bit mode may incur a page fault if paging does not map as 
read/write the section of the XSAVE area containing state component 7 (Hi16_ZMM state) — despite the fact that 
state component 7 can be accessed only in 64-bit mode. 
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CHAPTER 14 
PROGRAMMING WITH AVX, FMA AND AVX2 


Intel® Advanced Vector Extensions (Intel® AVX) introduces 256-bit vector processing capability. The Intel AVX 
instruction set extends 128-bit SIMD instruction sets by employing a new instruction encoding scheme via a vector 
extension prefix (VEX). Intel AVX also offers several enhanced features beyond those available in prior generations 
of 128-bit SIMD extensions. 


FMA (Fused Multiply Add) extensions enhances Intel AVX further in floating-point numeric computations. FMA 
provides high-throughput, arithmetic operations cover fused multiply-add, fused multiply-subtract, fused multiply 
add/subtract interleave, signed-reversed multiply on fused multiply-add and multiply-subtract. 


Intel AVX2 provides 256-bit integer SIMD extensions that accelerate computation across integer and floating-point 
domains using 256-bit vector registers. 


This chapter summarizes the key features of Intel AVX, FMA and AVX2. 


14.1. INTEL AVX OVERVIEW 


Intel AVX introduces the following architectural enhancements: 
® Support for 256-bit wide vectors with the YMM vector register set. 


° 256-bit floating-point instruction set enhancement with up to 2X performance gain relative to 128-bit 
Streaming SIMD extensions. 


¢ Enhancement of legacy 128-bit SIMD instruction extensions to support three-operand syntax and to simplify 
compiler vectorization of high-level language expressions. 


° VEX prefix-encoded instruction syntax support for generalized three-operand syntax to improve instruction 
programming flexibility and efficient encoding of new instruction extensions. 


° Most VEX-encoded 128-bit and 256-bit AVX instructions (with both load and computational operation 
semantics) are not restricted to 16-byte or 32-byte memory alignment. 


® Support flexible deployment of 256-bit AVX code, 128-bit AVX code, legacy 128-bit code and scalar code. 


With the exception of SIMD instructions operating on MMX registers, almost all legacy 128-bit SIMD instructions 
have AVX equivalents that support three operand syntax. 256-bit AVX instructions employ three-operand syntax 
and some with 4-operand syntax. 


14.1.1 256-Bit Wide SIMD Register Support 


Intel AVX introduces support for 256-bit wide SIMD registers (YMMO-YMM7 in operating modes that are 32-bit or 
less, YMMO-YMM15 in 64-bit mode). The lower 128-bits of the YMM registers are aliased to the respective 128-bit 
XMM registers. 


Legacy SSE instructions (i.e. SIMD instructions operating on XMM state but not using the VEX prefix, also referred 
to non-VEX encoded SIMD instructions) will not access the upper bits beyond bit 128 of the YMM registers. AVX 
instructions with a VEX prefix and vector length of 128-bits zeroes the upper bits (above bit 128) of the YMM 
register. 
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Figure 14-1. 256-Bit Wide SIMD Register 


14.1.2 — Instruction Syntax Enhancements 


Intel AVX employs an instruction encoding scheme using a new prefix (known as “VEX” prefix). Instruction 
encoding using the VEX prefix can directly encode a register operand within the VEX prefix. This support two new 
instruction syntax in Intel 64 architecture: 


¢ A non-destructive operand (in a three-operand instruction syntax): The non-destructive source reduces the 
number of registers, register-register copies and explicit load operations required in typical SSE loops, reduces 
code size, and improves micro-fusion opportunities. 


e A third source operand (in a four-operand instruction syntax) via the upper 4 bits in an 8-bit immediate field. 
Support for the third source operand is defined for selected instructions (e.g. VBLENDVPD, VBLENDVPS, 
PBLENDVB). 


Two-operand instruction syntax previously expressed in legacy SSE instruction as 
ADDPS xmm1, xmm2/m128 

128-bit AVX equivalent can be expressed in three-operand syntax as 
VADDPS xmm1, xmm2, xmm3/m128 


In four-operand syntax, the extra register operand is encoded in the immediate byte. 


Note SIMD instructions supporting three-operand syntax but processing only 128-bits of data are considered part 
of the 256-bit SIMD instruction set extensions of AVX, because bits 255:128 of the destination register are zeroed 
by the processor. 


14.1.3. VEX Prefix Instruction Encoding Support 


Intel AVX introduces a new prefix, referred to as VEX, in the Intel 64 and IA-32 instruction encoding format. 
Instruction encoding using the VEX prefix provides the following capabilities: 


¢ Direct encoding of a register operand within VEX. This provides instruction syntax support for non-destructive 
source operand. 


¢ Efficient encoding of instruction syntax operating on 128-bit and 256-bit register sets. 
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Compaction of REX prefix functionality: The equivalent functionality of the REX prefix is encoded within VEX. 


Compaction of SIMD prefix functionality and escape byte encoding: The functionality of SIMD prefix (66H, F2H, 
F3H) on opcode is equivalent to an opcode extension field to introduce new processing primitives. This 
functionality is replaced by a more compact representation of opcode extension within the VEX prefix. Similarly, 
the functionality of the escape opcode byte (OFH) and two-byte escape (OF38H, OF3AH) are also compacted 
within the VEX prefix encoding. 


Most VEX-encoded SIMD numeric and data processing instruction semantics with memory operand have 
relaxed memory alignment requirements than instructions encoded using SIMD prefixes (see Section 14.9). 


VEX prefix encoding applies to SIMD instructions operating on YMM registers, XMM registers, and in some cases 
with a general-purpose register as one of the operand. VEX prefix is not supported for instructions operating on 
MMX or x87 registers. Details of VEX prefix and instruction encoding are discussed in Chapter 2, “Instruction 
Format,” of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A. 


14.2 FUNCTIONAL OVERVIEW 


Intel AVX provide comprehensive functional improvements over previous generations of SIMD instruction exten- 
sions. The functional improvements include: 


256-bit floating-point arithmetic primitives: AVX enhances existing 128-bit floating-point arithmetic instruc- 
tions with 256-bit capabilities for floating-point processing. Table 14-1 lists SIMD instructions promoted to AVX. 


Enhancements for flexible SIMD data movements: AVX provides a number of new data movement primitives to 
enable efficient SIMD programming in relation to loading non-unit-strided data into SIMD registers, intra- 
register SIMD data manipulation, conditional expression and branch handling, etc. Enhancements for SIMD 
data movement primitives cover 256-bit and 128-bit vector floating-point data, and across 128-bit integer 
SIMD data processing using VEX-encoded instructions. 


Table 14-1. Promoted SSE/SSE2/SSE3/SSSE3/SSE4 Instructions 


VERe9 . VEN 12 2 Group Instruction If No, Reason? 
Encoding Encoding 
yes yes YY OF 1X MOVUPS 
no yes MOVSS scalar 
yes yes MOVUPD 
no yes MOVSD scalar 
no yes MOVLPS Note 1 
no yes MOVLPD Note 1 
no yes MOVLHPS Redundant with VPERMILPS 
yes yes MOVDDUP 
yes yes MOVSLDUP 
yes yes UNPCKLPS 
yes yes UNPCKLPD 
yes yes UNPCKHPS 
yes yes UNPCKHPD 
no yes MOVHPS Note 1 
no yes MOVHPD Note 1 
no yes MOVHLPS Redundant with VPERMILPS 
yes yes MOVAPS 
yes yes MOVSHDUP 
yes yes MOVAPD 
no no CVTPI2PS MMX 
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es ° vex le : Group Instruction If No, Reason? 
Encoding Encoding 
no yes CVTSI2SS scalar 
no no CVTPI2PD MMX 
no yes CVTSI2SD scalar 
no yes MOVNTPS 
no yes MOVNTPD 
no no CVTTPS2PI MMX 
no yes CVTTSS2SI scalar 
no no CVTTPD2PI MMX 
no yes CVTTSD2SI scalar 
no no CVTPS2PI MMX 
no yes CVTSS2SI scalar 
no no CVTPD2PI MMX 
no yes CVTSD2SI scalar 
no yes UCOMISS scalar 
no yes UCOMISD scalar 
no yes COMISS scalar 
no yes COMISD scalar 
yes yes YY OF 5X MOVMSKPS 
yes yes MOVMSKPD 
yes yes SQRTPS 
no yes SQRTSS scalar 
yes yes SQRTPD 
no yes SQRTSD scalar 
yes yes RSQRTPS 
no yes RSQRTSS scalar 
yes yes RCPPS 
no yes RCPSS scalar 
yes yes ANDPS 
yes yes ANDPD 
yes yes ANDNPS 
yes yes ANDNPD 
yes yes ORPS 
yes yes ORPD 
yes yes XORPS 
yes yes XORPD 
yes yes ADDPS 
no yes ADDSS scalar 
yes yes ADDPD 
no yes ADDSD scalar 
yes yes MULPS 
no yes MULSS scalar 
yes yes MULPD 
no yes MULSD scalar 
yes yes CVTPS2PD 
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eeeale tae Group Instruction If No, Reason? 
no yes CVTSS2SD scalar 
yes yes CVTPD2PS 
no yes CVTSD2SS scalar 
yes yes CVTDQ2PS 
yes yes CVTPS2DQ 
yes yes CVTTPS2DQ 
yes yes SUBPS 
no yes SUBSS scalar 
yes yes SUBPD 
no yes SUBSD scalar 
yes yes MINPS 
no yes MINSS scalar 
yes yes MINPD 
no yes MINSD scalar 
yes yes DIVPS 
no yes DIVSS scalar 
yes yes DIVPD 
no yes DIVSD scalar 
yes yes MAXPS 
no yes MAXSS scalar 
yes yes MAXPD 
no yes MAXSD scalar 
no yes YY OF 6X PUNPCKLBW Vi 
no yes PUNPCKLWD Vi 
no yes PUNPCKLDQ Vi 
no yes PACKSSWB Vi 
no yes PCMPGTB Vi 
no yes PCMPGTW Vi 
no yes PCMPGTD Vi 
no yes PACKUSWB Vi 
no yes PUNPCKHBW Vi 
no yes PUNPCKHWD Vi 
no yes PUNPCKHDQ Vi 
no yes PACKSSDW Vi 
no yes PUNPCKLQDQ Vi 
no yes PUNPCKHQDQ Vi 
no yes MOVD scalar 
no yes MOVQ scalar 
yes yes MOVDQA 
yes yes MOVDQU 
no yes YY OF 7X PSHUFD Vi 
no yes PSHUFHW Vi 
no yes PSHUFLW Vi 
no yes PCMPEQB Vi 
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es ° vex le : Group Instruction If No, Reason? 
Encoding Encoding 
no yes PCMPEQW Vi 
no yes PCMPEQD Vi 
yes yes HADDPD 
yes yes HADDPS 
yes yes HSUBPD 
yes yes HSUBPS 
no yes MOVD Vi 
no yes MOVQ Vi 
yes yes MOVDQA 
yes yes MOVDQU 
no yes YY OF AX LDMXCSR 
no yes STMXCSR 
yes yes YY OF CX CMPPS 
no yes CMPSS scalar 
yes yes CMPPD 
no yes CMPSD scalar 
no yes PINSRW Vi 
no yes PEXTRW Vi 
yes yes SHUFPS 
yes yes SHUFPD 
yes yes YY OF DX ADDSUBPD 
yes yes ADDSUBPS 
no yes PSRLW Vi 
no yes PSRLD Vi 
no yes PSRLQ Vi 
no yes PADDQ Vi 
no yes PMULLW Vi 
no no MOVQ2DQ MMX 
no no MOVDQ2Q MMX 
no yes PMOVMSKB Vi 
no yes PSUBUSB Vi 
no yes PSUBUSW Vi 
no yes PMINUB Vi 
no yes PAND Vi 
no yes PADDUSB Vi 
no yes PADDUSW Vi 
no yes PMAXUB Vi 
no yes PANDN Vi 
no yes YY OF EX PAVGB Vi 
no yes PSRAW Vi 
no yes PSRAD Vi 
no yes PAVGW Vi 
no yes PMULHUW Vi 
no yes PMULHW Vi 
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vEees . YER Ie : Group Instruction If No, Reason? 

Encoding Encoding 
yes yes CVTPD2DQ 
yes yes CVTTPD2DQ 
yes yes CVTDQ2PD 
no yes MOVNTDQ Vi 
no yes PSUBSB Vi 
no yes PSUBSW Vi 
no yes PMINSW Vi 
no yes POR Vi 
no yes PADDSB Vi 
no yes PADDSW Vi 
no yes PMAXSW Vi 
no yes PXOR Vi 
yes yes YY OF FX LDDQU Vi 
no yes PSLLW Vi 
no yes PSLLD Vi 
no yes PSLLOQ Vi 
no yes PMULUDQ Vi 
no yes PMADDWD Vi 
no yes PSADBW Vi 
no yes MASKMOVDQU 
no yes PSUBB Vi 
no yes PSUBW Vi 
no yes PSUBD Vi 
no yes PSUBQ Vi 
no yes PADDB Vi 
no yes PADDW Vi 
no yes PADDD Vi 
no yes SSSE3 PHADDW Vi 
no yes PHADDSW Vi 
no yes PHADDD Vi 
no yes PHSUBW Vi 
no yes PHSUBSW Vi 
no yes PHSUBD Vi 
no yes PMADDUBSW Vi 
no yes PALIGNR Vi 
no yes PSHUFB Vi 
no yes PMULHRSW Vi 
no yes PSIGNB Vi 
no yes PSIGNW Vi 
no yes PSIGND Vi 
no yes PABSB Vi 
no yes PABSW Vi 
no yes PABSD Vi 
yes yes SSE4.1 BLENDPS 
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Sains i Group Instruction If No, Reason? 
yes yes BLENDPD 
yes yes BLENDVPS Note 2 
yes yes BLENDVPD Note 2 
no yes DPPD 
yes yes DPPS 
no yes EXTRACTPS Note 3 
no yes INSERTPS Note 3 
no yes MOVNTDQA 
no yes MPSADBW Vi 
no yes PACKUSDW Vi 
no yes PBLENDVB Vi 
no yes PBLENDW Vi 
no yes PCMPEQQ Vi 
no yes PEXTRD Vi 
no yes PEXTRQ Vi 
no yes PEXTRB Vi 
no yes PEXTRW Vi 
no yes PHMINPOSUW Vi 
no yes PINSRB Vi 
no yes PINSRD Vi 
no yes PINSRQ Vi 
no yes PMAXSB Vi 
no yes PMAXSD Vi 
no yes PMAXUD Vi 
no yes PMAXUW Vi 
no yes PMINSB Vi 
no yes PMINSD Vi 
no yes PMINUD Vi 
no yes PMINUW Vi 
no yes PMOVSXxx Vi 
no yes PMOVZXxx Vi 
no yes PMULDQ Vi 
no yes PMULLD Vi 
yes yes PTEST 
yes yes ROUNDPD 
yes yes ROUNDPS 
no yes ROUNDSD scalar 
no yes ROUNDSS scalar 
no yes SSE4.2 PCMPGTQ Vi 
no no SSE4.2 CRC32c integer 
no yes PCMPESTRI Vi 
no yes PCMPESTRM Vi 
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i tae Group Instruction If No, Reason? 
no yes PCMPISTRI Vi 
no yes PCMPISTRM Vi 
no no SSE4.2 POPCNT integer 


14.2.1. 256-bit Floating-Point Arithmetic Processing Enhancements 


Intel AVX provides 35 256-bit floating-point arithmetic instructions, see Table 14-2. The arithmetic operations 
cover add, subtract, multiply, divide, square-root, compare, max, min, round, etc., on single-precision and double- 
precision floating-point data. 

The enhancement in AVX on floating-point compare operation provides 32 conditional predicates to improve 
programming flexibility in evaluating conditional expressions. 


Table 14-2. Promoted 256-Bit and 128-bit Arithmetic AVX Instructions 


VEX.256 Encoding VEX.128 Encoding Legacy Instruction Mnemonic 
yes yes SQRTPS, SQRTPD, RSQRTPS, RCPPS 
yes yes ADDPS, ADDPD, SUBPS, SUBPD 
yes yes MULPS, MULPD, DIVPS, DIVPD 
yes yes CVTPS2PD, CVTPD2PS 
yes yes CVTDQ2PS, CVTPS2DQ 
yes yes CVTTPS2DQ, CVTTPD2DQ 
yes yes CVTPD2DQ, CVTDQ2PD 
yes yes MINPS, MINPD, MAXPS, MAXPD 
yes yes HADDPD, HADDPS, HSUBPD, HSUBPS 
yes yes CMPPS, CMPPD 
yes yes ADDSUBPD, ADDSUBPS, DPPS 
yes yes ROUNDPD, ROUNDPS 


14.2.2 256-bit Non-Arithmetic Instruction Enhancements 


Intel AVX provides new primitives for handling data movement within 256-bit floating-point vectors and promotes 
many 128-bit floating data processing instructions to handle 256-bit floating-point vectors. 


AVX includes 39 256-bit data movement and processing instructions that are promoted from previous generations 
of SIMD instruction extensions, ranging from logical, blend, convert, test, unpacking, shuffling, load and stores 
(see Table 14-3). 


Table 14-3. Promoted 256-bit and 128-bit Data Movement AVX Instructions 


VEX.256 Encoding VEX.128 Encoding Legacy Instruction Mnemonic 
yes yes MOVAPS, MOVAPD, MOVDQA 
yes yes MOVUPS, MOVUPD, MOVDQU 
yes yes MOVMSKPS, MOVMSKPD 
yes yes LDDQU, MOVNTPS, MOVNTPD, MOVNTDQ, MOVNTDQA 
yes yes MOVSHDUP, MOVSLDUP, MOVDDUP 
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Table 14-3. Promoted 256-bit and 128-bit Data Movement AVX Instructions 


VEX.256 Encoding VEX.128 Encoding Legacy Instruction Mnemonic 
yes yes UNPCKHPD, UNPCKHPS, UNPCKLPD 
yes yes BLENDPS, BLENDPD 
yes yes SHUFPD, SHUFPS, UNPCKLPS 
yes yes BLENDVPS, BLENDVPD 
yes yes PTEST, MOVMSKPD, MOVMSKPS 
yes yes XORPS, XORPD, ORPS, ORPD 
yes yes ANDNPD, ANDNPS, ANDPD, ANDPS 


AVX introduces 18 new data processing instructions that operate on 256-bit vectors, Table 14-4. These new primi- 
tives cover the following operations: 


¢ Non-unit-strided fetching of SIMD data. AVX provides several flexible SIMD floating-point data fetching 
primitives: 
— broadcast of single or multiple data elements into a 256-bit destination, 
— masked move primitives to load or store SIMD data elements conditionally, 


*  Intra-register manipulation of SIMD data elements. AVX provides several flexible SIMD floating-point data 
manipulation primitives: 


— insert/extract multiple SIMD floating-point data elements to/from 256-bit SIMD registers 


— permute primitives to facilitate efficient manipulation of floating-point data elements in 256-bit SIMD 
registers 


¢ Branch handling. AVX provides several primitives to enable handling of branches in SIMD programming: 


— new variable blend instructions supports four-operand syntax with non-destructive source syntax. This is 
more flexible than the equivalent SSE4 instruction syntax which uses the XMMO register as the implied 
mask for blend selection. 


— Packed TEST instructions for floating-point data. 


Table 14-4. 256-bit AVX Instruction Enhancement 


Instruction Description 

VBROADCASTF128 ymm1, m128 Broadcast 128-bit floating-point values in mem to low and high 128-bits in ymm1. 

VBROADCASTSD ymm1, m64 Broadcast double-precision floating-point element in mem to four locations in ymm1. 

VBROADCASTSS ymm1, m32 Broadcast single-precision floating-point element in mem to eight locations in ymm1. 

VEXTRACTF128 xmm1/m128, ymm2, Extracts 128-bits of packed floating-point values from ymm2 and store results in 

imm8 xmm1/mem. 

VINSERTF128 ymm1, ymm2, Insert 128-bits of packed floating-point values from xmm3/mem and the remaining val- 

xmm3/m128, imm8 ues from ymm2 into ymm1 

VMASKMOVPS ymm1, ymm2, m256 Load packed single-precision values from mem using mask in ymm2 and store in ymm1 

VMASKMOVPD ymm1, ymm2, m256 Load packed double-precision values from mem using mask in ymm2 and store in ymm1 

VMASKMOVPS m256, ymm1, ymm2 Store packed single-precision values from ymm2 mask in ymm1 

VMASKMOVPD m256, ymm1, ymm2 Store packed double-precision values from ymm_2 using mask in ymm1 

VPERMILPD ymm1, ymm2, ymm3/m256__‘| Permute Double-Precision Floating-Point values in ymm2 using controls from xmm3/mem 
and store result in ymm1 
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Table 14-4. 256-bit AVX Instruction Enhancement 


Instruction Description 


VPERMILPD ymm1, ymm2/m256 imm8 Permute Double-Precision Floating-Point values in ymm2/mem using controls from imm8 
and store result in ymm1 


VPERMILPS ymm1, ymm2, ymm/m256 Permute Single-Precision Floating-Point values in ymm2 using controls from ymm3/mem 
and store result in ymm1 


VPERMILPS ymm1, ymm2/m256, imm8 Permute Single-Precision Floating-Point values in ymm2/mem using controls from imm8 
and store result in ymm1 


VPERM2F128 ymm1, ymm2, Permute 128-bit floating-point fields in ymm2 and ymm3/mem using controls from imm8 

ymm3/m256, imm8 and store result in ymm1 

VTESTPS ymm1, ymm2/m256 Set ZF if ymm2/mem AND ymm1 result is all Os in packed single-precision sign bits. Set CF 
if ymnm2/mem AND NOT ymm1 result is all Os in packed single-precision sign bits. 

VTESTPD ymm1, ymm2/m256 Set ZF if ymnm2/mem AND ymm1 result is all Os in packed double-precision sign bits. Set 
CF if ymnm2/mem AND NOT ymm1 result is all Os in packed double-precision sign bits. 

VZEROALL Zero all YMM registers 

VZEROUPPER Zero upper 128 bits of all YMM registers 


14.2.3. Arithmetic Primitives for 128-bit Vector and Scalar processing 


Intel AVX provides a full complement of 128-bit numeric processing instructions that employ VEX-prefix encoding. 
These VEX-encoded instructions generally provide the same functionality over instructions operating on XMM 
register that are encoded using SIMD prefixes. The 128-bit numeric processing instructions in AVX cover floating- 
point and integer data processing; across 128-bit vector and scalar processing. Table 14-5 lists the state of promo- 
tion of legacy SIMD arithmetic ISA to VEX-128 encoding. Legacy SIMD floating-point arithmetic ISA promoted to 
VEX-256 encoding also support VEX-128 encoding (see Table 14-2). 


The enhancement in AVX on 128-bit floating-point compare operation provides 32 conditional predicates to 
improve programming flexibility in evaluating conditional expressions. This contrasts with floating-point SIMD 
compare instructions in SSE and SSE2 supporting only 8 conditional predicates. 


Table 14-5. Promotion of Legacy SIMD ISA to 128-bit Arithmetic AVX instruction 


Boal ee sang Instruction Reason Not Promoted 

no no CVTPI2PS, CVTPI2PD, CVTPD2PI MMX 
no no CVTTPS2PI, CVTTPD2PI, CVTPS2PI MMX 
no yes CVTSI2SS, CVTSI2SD, CVTSD2SI scalar 
no yes CVTTSS2SI, CVTTSD2SI, CVTSS2SI scalar 
no yes COMISD, RSQRTSS, RCPSS scalar 
no yes UCOMISS, UCOMISD, COMISS, scalar 
no yes ADDSS, ADDSD, SUBSS, SUBSD scalar 
no yes MULSS, MULSD, DIVSS, DIVSD scalar 
no yes SQRTSS, SQRTSD scalar 
no yes CVTSS2SD, CVTSD2SS scalar 
no yes MINSS, MINSD, MAXSS, MAXSD scalar 
no yes PAND, PANDN, POR, PXOR Vl 

no yes PCMPGTB, PCMPGTW, PCMPGTD Vl 
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Table 14-5. Promotion of Legacy SIMD ISA to 128-bit Arithmetic AVX instruction 


eine eradca Instruction Reason Not Promoted 

no yes PMADDWD, PMADDUBSW Vl 

no yes PAVGB, PAVGW, PMULUDQ Vl 

no yes PCMPEQB, PCMPEQW, PCMPEQD Vi 

no yes PMULLW, PMULHUW, PMULHW Vl 

no yes PSUBSW, PADDSW, PSADBW Vl 

no yes PADDUSB, PADDUSW, PADDSB Vl 

no yes PSUBUSB, PSUBUSW, PSUBSB Vl 

no yes PMINUB, PMINSW Vl 

no yes PMAXUB, PMAXSW Vl 

no yes PADDB, PADDW, PADDD, PADDQ Vl 

no yes PSUBB, PSUBW, PSUBD, PSUBQ Vl 

no yes PSLLW, PSLLD, PSLLQ, PSRAW Vl 

no yes PSRLW, PSRLD, PSRLQ, PSRAD Vl 
CPUID.SSSE3 

no yes PHSUBW, PHSUBD, PHSUBSW Vl 

no yes PHADDW, PHADDD, PHADDSW Vl 

no yes PMULHRSW Vi 

no yes PSIGNB, PSIGNW, PSIGND Vl 

no yes PABSB, PABSW, PABSD Vl 
CPUID.SSE4_1 

no yes DPPD 

no yes PHMINPOSUW, MPSADBW Vl 

no yes PMAXSB, PMAXSD, PMAXUD Vl 

no yes PMINSB, PMINSD, PMINUD Vl 

no yes PMAXUW, PMINUW Vl 

no yes PMOVSXxx, PMOVZXxx Vi 

no yes PMULDQ, PMULLD Vi 

no yes ROUNDSD, ROUNDSS scalar 
CPUID.POPCNT 

no yes POPCNT integer 
CPUID.SSE4_2 

no yes PCMPGTQ Vi 

no no CRC32 integer 

no yes PCMPESTRI, PCMPESTRM Vl 

no yes PCMPISTRI, PCMPISTRM Vl 
CPUID.CLMUL 

no yes PCLMULQDQ Vl 
CPUID.AESNI 
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Table 14-5. Promotion of Legacy SIMD ISA to 128-bit Arithmetic AVX instruction 


eet ae Instruction Reason Not Promoted 
no yes AESDEC, AESDECLAST Vl 
no yes AESENC, AESENCLAST Vl 
no yes AESIMX, AESKEYGENASSIST Vl 


Description of Column “Reason not promoted?” 

MMx: Instructions referencing MMX registers do not support VEX 
Scalar: Scalar instructions are not promoted to 256-bit 

integer: integer instructions are not promoted. 

VI: “Vector Integer” instructions are not promoted to 256-bit 


14.2.4 Non-Arithmetic Primitives for 128-bit Vector and Scalar Processing 

Intel AVX provides a full complement of data processing instructions that employ VEX-prefix encoding. These VEX- 

encoded instructions generally provide the same functionality over instructions operating on XMM register that are 

encoded using SIMD prefixes. 

A subset of new functionalities listed in Table 14-4 is also extended via VEX.128 encoding. These enhancements in 

AVX on 128-bit data processing primitives include 11 new instructions (see Table 14-6) with the following capabil- 

ities: 

* Non-unit-strided fetching of SIMD data. AVX provides several flexible SIMD floating-point data fetching 
primitives: 

— broadcast of single data element into a 128-bit destination, 

— masked move primitives to load or store SIMD data elements conditionally, 

¢  Intra-register manipulation of SIMD data elements. AVX provides several flexible SIMD floating-point data 
manipulation primitives: 

— permute primitives to facilitate efficient manipulation of floating-point data elements in 128-bit SIMD 
registers 

¢ Branch handling. AVX provides several primitives to enable handling of branches in SIMD programming: 

— new variable blend instructions supports four-operand syntax with non-destructive source syntax. 
Branching conditions dependent on floating-point data or integer data can benefit from Intel AVX. This is 
more flexible than non-VEX encoded instruction syntax that uses the XMMO register as implied mask for 
blend selection. While variable blend with implied XMMO syntax is supported in SSE4 using SIMD prefix 


encoding, VEX-encoded 128-bit variable blend instructions only support the more flexible four-operand 
syntax. 


— Packed TEST instructions for floating-point data. 


Table 14-6. 128-bit AVX Instruction Enhancement 


Instruction Description 

VBROADCASTSS xmm1, m32 Broadcast single-precision floating-point element in mem to four locations in xmm1. 
VMASKMOVPS xmm1, xmm2, m128 Load packed single-precision values from mem using mask in xmm2 and store in xmm1 
VMASKMOVPD xmm1, xmm2, m128 Load packed double-precision values from mem using mask in xmm2 and store in xmm1 
VMASKMOVPS m128, xmm1, xmm2 Store packed single-precision values from xmm2 using mask in xmm1 

VMASKMOVPD m1 28, xmm1, xmm2 Store packed double-precision values from xmm_2 using mask in xmm1 
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Table 14-6. 128-bit AVX Instruction Enhancement 


Instruction Description 


VPERMILPD xmm1, xmm2, xmm3/m128 | Permute Double-Precision Floating-Point values in xmm2 using controls from xmm3/mem 
and store result in xmm1 


VPERMILPD xmm1, xmm2/m128, imm8 Permute Double-Precision Floating-Point values in xmm2/mem using controls from imm8 
and store result in xmm1 


VPERMILPS xmm1, xmm2, xmm3/m128 | Permute Single-Precision Floating-Point values in xmm2 using controls from xmm3/mem 
and store result in xmm1 


VPERMILPS xmm1, xmm2/m1 28, imm8 Permute Single-Precision Floating-Point values in xmm2/mem using controls from imm8 
and store result in xmm1 


VTESTPS xmm1, xmm2/m128 Set ZF if xmm2/mem AND xmm1 result is all Os in packed single-precision sign bits. Set 
CF if xmm2/mem AND NOT xmm1 result is all Os in packed single-precision sign bits. 


VTESTPD xmm1, xmm2/m128 Set ZF if xmm2/mem AND xmm1 result is all Os in packed single precision sign bits. Set CF 
if xmm2/mem AND NOT xmm1 result is all Os in packed double-precision sign bits. 


The 128-bit data processing instructions in AVX cover floating-point and integer data movement primitives. Legacy 
SIMD non-arithmetic ISA promoted to VEX-256 encoding also support VEX-128 encoding (see Table 14-3). Table 
14-7 lists the state of promotion of the remaining legacy SIMD non-arithmetic ISA to VEX-128 encoding. 


Table 14-7. Promotion of Legacy SIMD ISA to 128-bit Non-Arithmetic AVX instruction 


an ercdne Instruction Reason Not Promoted 

no no MOVQ2DQ, MOVDQ20 MMX 

no yes LDMXCSR, STMXCSR 

no yes MOVSS, MOVSD, CMPSS, CMPSD scalar 

no yes MOVHPS, MOVHPD Note 1 

no yes MOVLPS, MOVLPD Note 1 

no yes MOVLHPS, MOVHLPS Redundant with VPERMILPS 

no yes MOVQ, MOVD scalar 

no yes PACKUSWB, PACKSSDW, PACKSSWB Vl 

no yes PUNPCKHBW, PUNPCKHWD Vl 

no yes PUNPCKLBW, PUNPCKLWD Vl 

no yes PUNPCKHDQ, PUNPCKLDQ Vi 

no yes PUNPCKLQDQ, PUNPCKHQDQ Vl 

no yes PSHUFHW, PSHUFLW, PSHUFD Vl 

no yes PMOVMSKB, MASKMOVDQU Vl 

no yes PAND, PANDN, POR, PXOR Vl 

no yes PINSRW, PEXTRW, Vl 
CPUID.SSSE3 

no yes PALIGNR, PSHUFB Vl 
CPUID.SSE4_1 

no yes EXTRACTPS, INSERTPS Note 3 

no yes PACKUSDW, PCMPEQQ Vi 
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Table 14-7. Promotion of Legacy SIMD ISA to 128-bit Non-Arithmetic AVX instruction 


edna ercading Instruction Reason Not Promoted 
no yes PBLENDVB, PBLENDW Vl 
no yes PEXTRW, PEXTRB, PEXTRD, PEXTRQ Vl 
no yes PINSRB, PINSRD, PINSRQ Vl 


Description of Column “Reason not promoted?” 

MMx: Instructions referencing MMX registers do not support VEX 
Scalar: Scalar instructions are not promoted to 256-bit 

VI: “Vector Integer” instructions are not promoted to 256-bit 


Note 1: MOVLPD/PS and MOVHPD/PS are not promoted to 256-bit. The equivalent functionality are provided by 
VINSERTF128 and VEXTRACTF128 instructions as the existing instructions have no natural 256b extension 


Note 3: It is expected that using 128-bit INSERTPS followed by a VINSERTF128 would be better than promoting 
INSERTPS to 256-bit (for example). 


14.3, DETECTION OF AVX INSTRUCTIONS 


Intel AVX instructions operate on the 256-bit YMM register state. Application detection of new instruction exten- 
sions operating on the YMM state follows the general procedural flow in Figure 14-2. 


Prior to using AVX, the application must identify that the operating system supports the XGETBV instruction, the 
YMM register state, in addition to processor’s support for YMM state management using XSAVE/XRSTOR and AVX 
instructions. The following simplified sequence accomplishes both and is strongly recommended. 


1) Detect CPUID.1:ECX.OSXSAVE[bit 27] = 1 (XGETBV enabled for application use?) 

2) Issue XGETBV and verify that XCRO[2:1] =‘11b’ (XMM state and YMM state are enabled by OS). 
3) detect CPUID.1:ECX.AVX[bit 28] = 1 (AVX instructions supported). 

(Step 3 can be done in any order relative to 1 and 2) 


Check feature flag 
CPUID.1H:ECX.OSXSAVE = 1? 


OS provides processor 
extended state management 


Yes 


Implied HW support for 
XSAVE, XRSTOR, XGETBV, XCRO 


Check enabled state in . Check feature flag 
XCRO via XGETBV State for Instruction set ok to use 
enabled Instructions 


Figure 14-2. General Procedural Flow of Application Detection of AVX 


1. IfCPUID.01H:ECX.OSXSAVE reports 1, it also indirectly implies the processor supports XSAVE, XRSTOR, XGETBV, processor 
extended state bit vector XCRO. Thus an application may streamline the checking of CPUID feature flags for XSAVE and OSXSAVE. 
XSETBV is a privileged instruction. 
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The following pseudocode illustrates this recommended application AVX detection process: 


Example 14-1. Detection of AVX Instruction 


INT supports_AVX() 
{ mov eax, 1 
cpuid 
and ecx, 018000000H 
cmp ecx, 018000000H; check both OSXSAVE and AVX feature flags 
jne not_supported 
; processor supports AVX instructions and XGETBV is enabled by OS 
mov ecx, 0; specify O for XCRO register 
XGETBV ; result in EDX:EAX 
and eax, O6H 
cmp eax, OGH; check OS has enabled both XMM and YMM state support 


jne not_supported 
mov eax, 1 
jmp done 


NOT_SUPPORTED: 
mov eax, 0 
done: 


Note: It is unwise for an application to rely exclusively on CPUID.1:ECX.AVX[bit 28] or at all on 
CPUID.1:ECX.XSAVE[bit 26]: These indicate hardware support but not operating system support. If YMM state 
management is not enabled by an operating systems, AVX instructions will #UD regardless of 
CPUID.1:ECX.AVX[bit 28]. “CPUID.1:ECX.XSAVE[bit 26] = 1” does not guarantee the OS actually uses the XSAVE 


process for state management. 


These steps above also apply to enhanced 128-bit SIMD floating-pointing instructions in AVX (using VEX prefix- 
encoding) that operate on the YMM states. 
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14.3.1 Detection of VEX-Encoded AES and VPCLMULQDQ 


VAESDEC/VAESDECLAST/VAESENC/VAESENCLAST/VAESIMC/VAESKEYGENASSIST instructions operate on YMM 
states. The detection sequence must combine checking for CPUID.1:ECX.AES[bit 25] = 1 and the sequence for 
detection application support for AVX. 


Example 14-2. Detection of VEX-Encoded AESNI Instructions 


INT supports_VAESNI() 
{ mov eax, 1 
cpuid 
and ecx, 01AO00000H 
cmp ecx, 01 AOO00000H; check OSXSAVE AVX and AESNI feature flags 
jne not_supported 
; processor supports AVX and VEX-encoded AESNI and XGETBV is enabled by OS 
mov ecx, 0; specify O for XCRO register 
XGETBV ; result in EDX:EAX 
and eax, O6H 
cmp eax, OGH; check OS has enabled both XMM and YMM state support 


jne not_supported 
mov eax, 1 
jmp done 


NOT_SUPPORTED: 
mov eax, 0 
done: 


Similarly, the detection sequence for VPCLMULQDQ must combine checking for CPUID.1:ECX.PCLMULQDQJ[bit 1] = 
1 and the sequence for detection application support for AVX. 


This is shown in the pseudocode: 


Example 14-3. Detection of VEX-Encoded AESNI Instructions 


INT supports_VPCLMULQDQ) 
{ mov eax, 1 
cpuid 
and ecx, 018000002H 
cmp ecx, 018000002H; check OSXSAVE AVX and PCLMULQDQ feature flags 
jne not_supported 
; processor supports AVX and VEX-encoded PCLMULQDQ and XGETBV is enabled by OS 
mov ecx, 0; specify O for XCRO register 
XGETBV ; result in EDX:EAX 
and eax, O6H 
cmp eax, OGH; check OS has enabled both XMM and YMM state support 
jne not_supported 


mov eax, 1 

jmp done 
NOT_SUPPORTED: 

mov eax, 0 
done: 
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14.4 HALF-PRECISION FLOATING-POINT CONVERSION 


VCVTPH2PS and VCVTPS2PH are two instructions supporting half-precision floating-point data type conversion to 
and from single-precision floating-point data types. 


Half-precision floating-point values are not used by the processor directly for arithmetic operations. But the conver- 
sion operation are subject to SIMD floating-point exceptions. 


Additionally, The conversion operations of VCVTPS2PH allow programmer to specify rounding control using control 
fields in an immediate byte. The effects of the immediate byte are listed in Table 14-8. 


Rounding control can use Imm[2] to select an override RC field specified in Imm[1:0] or use MXCSR setting. 


Table 14-8. Immediate Byte Encoding for 16-bit Floating-Point Conversion Instructions 


Bits Field Name/value Description Comment 
Imm[1:0] RC=00B Round to nearest even If Imm[2] = 0 
RC=01B Round down 
RC=10B Round up 
RC=11B Truncate 
Imm[2] MS1=0 Use imm[1:0] for rounding Ignore MXCSR.RC 
MS1=1 Use MXCSR.RC for rounding 
Imm[7:3] Ignored Ignored by processor 


Specific SIMD floating-point exceptions that can occur in conversion operations are shown in Table 14-9 and 
Table 14-10. 


Table 14-9. Non-Numerical Behavior for VCVTPH2PS, VCVTPS2PH 


Source Operands Masked Result Unmasked Result 
QNaN QNaN1! QNaN1! (not an exception) 
SNaN QNaN1¢ None 
NOTES: 


1. The half precision output QNaN1 is created from the single precision input QNaN as follows: the sign bit is preserved, the 8-bit expo- 
nent FFH is replaced by the 5-bit exponent 1FH, and the 24-bit significand is truncated to an 11-bit significand by removing its 14 
least significant bits. 

2. The half precision output QNaN1 is created from the single precision input SNaN as follows: the sign bit is preserved, the 8-bit expo- 
nent FFH is replaced by the 5-bit exponent 1FH, and the 24-bit significand is truncated to an 11-bit significand by removing its 14 
least significant bits. The second most significant bit of the significand is changed from O to 1 to convert the signaling NaN into a quiet 
NaN. 


Table 14-10. Invalid Operation for VCVTPH2PS, VCVTPS2PH 


Instruction Condition Masked Result Unmasked Result 
VCVTPH2PS SRC = NaN See Table 14-9 #I=1 
VCVTPS2PH SRC = NaN See Table 14-9 #I=1 


VCVTPS2PH can cause denormal exceptions if the value of the source operand is denormal relative to the numer- 


ical range represented by the source format (see Table 14-11). 
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Table 14-11. Denormal Condition Summary 


Instruction Condition Masked Result Unmasked Result 
VCVTPH2PS__| SRC is denormal relative to res = Result rounded to the destination precision and Same as masked result. 
input format using the bounded exponent, but only if no unmasked 
post-computation exception occurs. 
#DE unchanged 
VCVTPS2PH | SRC is denormal relative to res = Result rounded to the destination precision and #DE=1 
input format using the bounded exponent, but only if no unmasked 
post-computation exception occurs. 
#DE=1 


VCVTPS2PH can cause an underflow exception if the result of the conversion is less than the underflow threshold 
for half-precision floating-point data type , i.e. | x |< 1.0 * 2-44, 


Table 14-12. Underflow Condition for VCVTPS2PH 


Instruction Condition Masked Result! Unmasked Result 
VCVTPS2PH Result < smallest destination Result = +0 or -0, denormal, normal. #UE=1, 
precision final normal value HUE =1. #PE = 1 if the result is 
#PE = 1 if the result is inexact. inexact. 
NOTES: 


1. Masked and unmasked results are shown in Table 14-11. 
2. MXCSR.FTZ is ignored, the processor behaves as if MXCSR.FTZ = 0. 


VCVTPS2PH can cause an overflow exception if the result of the conversion is greater than the maximum repre- 
sentable value for half-precision floating-point data type, i.e. | x | > 1.0 « 216. 


Table 14-13. Overflow Condition for VCVTPS2PH 
Instruction Condition Masked Result Unmasked Result 


VCVTPS2PH _ | Result > largest destination Result = +Inf or -Inf. #OE=1. 


precision finial normal value! | #0¢=1. 


VCVTPS2PH can cause an inexact exception if the result of the conversion is not exactly representable in the 
destination format. 


Table 14-14. Inexact Condition for VCVTPS2PH 


Instruction Condition Masked Result! Unmasked Result 
VCVTPS2PH The result is not res = Result rounded to the destination Only if no underflow/overflow condition occurred, 
representable in precision and using the bounded or if the corresponding exceptions are masked: 
the destination exponent, but only if no unmasked * Set #0E if masked overflow and set result as 
format underflow or overflow conditions occur described above for masked overflow. 


(this exception can occur in the presence 
of a masked underflow or overflow). 


#PE=1. 


« Set #UE if masked underflow and set result as 
described above for masked underflow. 


If neither underflow nor overflow, result equals 
the result rounded to the destination precision and 
using the bounded exponent set #PE = 1. 


NOTES: 
1. If a source is denormal relative to input format with DM masked and at least one of PM or UM unmasked, then an exception will be 
raised with DE, UE and PE set. 
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14.4.1. Detection of F16C Instructions 

Application using float 16 instruction must follow a detection sequence similar to AVX to ensure: 

° The OS has enabled YMM state management support, 

¢ The processor support AVX as indicated by the CPUID feature flag, i.e. CPUID.0O1H:ECX.AVX[bit 28] = 1. 


¢ The processor support 16-bit floating-point conversion instructions via a CPUID feature flag 
(CPUID.01H:ECX.F16C[bit 29] = 1). 


Application detection of Float-16 conversion instructions follow the general procedural flow in Figure 14-3. 


Check feature flag 
CPUID.1H:ECX.OSXSAVE = 1? 


OS provides processor 
extended state management 
Yes Implied HW support for 
XSAVE, XRSTOR, XGETBV, XCRO 


Check enabled YMM state in |__| Check feature flags 


—_> 
XCRO via XGETBV State for AVX and F16C ok to use 
enabled Instructions 


Figure 14-3. General Procedural Flow of Application Detection of Float-16 


INT supports_f16c() 
{ ; result in eax 
mov eax, 1 
cpuid 
and ecx, 038000000H 
cmp ecx, 038000000H; check OSXSAVE, AVX, F16C feature flags 
jne not_supported 
; processor supports AVX,F16C instructions and XGETBV is enabled by OS 
mov ecx, 0; specify 0 for XCRO register 
XGETBV; result in EDX:EAX 
and eax, 06H 
cmp eax, 06H; check OS has enabled both XMM and YMM state support 
jne not_supported 
mov eax, 1 
jmp done 
NOT_SUPPORTED: 
mov eax, 0 
done: 
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14.5 FUSED-MULTIPLY-ADD (FMA) EXTENSIONS 


FMA extensions enhances Intel AVX with high-throughput, arithmetic capabilities covering fused multiply-add, 
fused multiply-subtract, fused multiply add/subtract interleave, signed-reversed multiply on fused multiply-add 
and multiply-subtract. FMA extensions provide 36 256-bit floating-point instructions to perform computation on 
256-bit vectors and additional 128-bit and scalar FMA instructions. 


FMA extensions also provide 60 128-bit floating-point instructions to process 128-bit vector and scalar data. The 
arithmetic operations cover fused multiply-add, fused multiply-subtract, signed-reversed multiply on fused 


multiply-add and multiply-subtract. 


Table 14-15. FMA Instructions 


Instruction 


Description 


VFMADD132PD/VFMADD213PD/VFMADD231PD 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Multiply-Add of Packed Double-Precision Floating-Point 
Values 


VFMADD132PS/VFMADD21 3PS/VFMADD231PS 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Multiply-Add of Packed Single-Precision Floating-Point 
Values 


VFMADD132SD/VFMADD213SD/VFMADD231SD 
xmmo0, xmm1, xmm2/m64 


Fused Multiply-Add of Scalar Double-Precision Floating-Point 
Values 


VFMADD132SS/VFMADD213SS/VFMADD231SS 
xmmo0, xmm1, xmm2/m32 


Fused Multiply-Add of Scalar Single-Precision Floating-Point 
Values 


VFMADDSUB1 32PD/VFMADDSUB21 3PD/VFMADDSUB231PD 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Multiply-Alternating Add/Subtract of Packed Double- 
Precision Floating-Point Values 


VFMADDSUB1 32PS/VFMADDSUB2 1 3PS/VFMADDSUB231PS 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Multiply-Alternating Add/Subtract of Packed Single-Pre- 
cision Floating-Point Values 


VFMSUBADD1 32PD/VFMSUBADD2 1 3PD/VFMSUBADD231PD 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Multiply-Alternating Subtract/Add of Packed Double- 
Precision Floating-Point Values 


VFMSUBADD132PS/VFMSUBADD2 1 3PS/VFMSUBADD231PS 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Multiply-Alternating Subtract/Add of Packed Single-Pre- 
cision Floating-Point Values 


VFMSUB132PD/VFMSUB213PD/VFMSUB231PD 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Multiply-Subtract of Packed Double-Precision Floating- 
Point Values 


VFMSUB132PS/VFMSUB21 3PS/VFMSUB231PS 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Multiply-Subtract of Packed Single-Precision Floating- 
Point Values 


VFMSUB132SD/VFMSUB213SD/VFMSUB231SD 
xmmo0, xmm1, xmm2/m64 


Fused Multiply-Subtract of Scalar Double-Precision Floating- 
Point Values 


VFMSUB132SS/VFMSUB213SS/VFMSUB231SS 
xmmo0, xmm1, xmm2/m32 


Fused Multiply-Subtract of Scalar Single-Precision Floating- 
Point Values 


VFNMADD132PD/VFNMADD21 3PD/VFNMADD231PD 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Negative Multiply-Add of Packed Double-Precision Float- 
ing-Point Values 


VFNMADD132PS/VFNMADD213PS/VFNMADD231PS 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Negative Multiply-Add of Packed Single-Precision Float- 
ing-Point Values 


VFNMADD132SD/VFNMADD213SD/VFNMADD231SD 
xmmo0, xmm1, xmm2/m64 


Fused Negative Multiply-Add of Scalar Double-Precision Float- 
ing-Point Values 


VFNMADD132SS/VFNMADD213SS/VFNMADD231SS 
xmmo0, xmm1, xmm2/m32 


Fused Negative Multiply-Add of Scalar Single-Precision Float- 
ing-Point Values 


VFNMSUB1 32PD/VFNMSUB21 3PD/VFNMSUB231PD 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Negative Multiply-Subtract of Packed Double-Precision 
Floating-Point Values 


VFNMSUB132PS/VFNMSUB213PS/VFNMSUB231PS 
xmm0, xmm1, xmm2/m128; ymmO, ymm1, ymm2/m256 


Fused Negative Multiply-Subtract of Packed Single-Precision 
Floating-Point Values 
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Table 14-15. FMA Instructions 


Instruction Description 

VFNMSUB1 32SD/VFNMSUB21 3SD/VFNMSUB231SD Fused Negative Multiply-Subtract of Scalar Double-Precision 
xmm0, xmm1, xmm2/m64 Floating-Point Values 
VFNMSUB132SS/VFNMSUB213SS/VFNMSUB231SS Fused Negative Multiply-Subtract of Scalar Single-Precision 
xmm0, xmm1, xmm2/m32 Floating-Point Values 


14.5.1 | FMA Instruction Operand Order and Arithmetic Behavior 


FMA instruction mnemonics are defined explicitly with an ordered three digits, e.g. VFMADD132PD. The value of 
each digit refers to the ordering of the three source operand as defined by instruction encoding specification: 


e ‘1’: The first source operand (also the destination operand) in the syntactical order listed in this specification. 
e ‘2': The second source operand in the syntactical order. This is a YMM/XMM register, encoded using VEX prefix. 


¢ ‘3’: The third source operand in the syntactical order. The first and third operand are encoded following ModR/M 
encoding rules. 


The ordering of each digit within the mnemonic refers to the floating-point data listed on the right-hand side of the 
arithmetic equation of each FMA operation (see Table 14-17): 


¢ The first position in the three digits of a FMA mnemonic refers to the operand position of the first FP data 
expressed in the arithmetic equation of FMA operation, the multiplicand. 


¢ The second position in the three digits of a FMA mnemonic refers to the operand position of the second FP data 
expressed in the arithmetic equation of FMA operation, the multiplier. 


¢ The third position in the three digits of a FMA mnemonic refers to the operand position of the FP data being 
added/subtracted to the multiplication result. 


Note the non-numerical result of an FMA operation does not resemble the mathematically-defined commutative 
property between the multiplicand and the multiplier values (see Table 14-17). Consequently, software tools (such 
as an assembler) may support a complementary set of FMA mnemonics for each FMA instruction for ease of 
programming to take advantage of the mathematical property of commutative multiplications. For example, an 
assembler may optionally support the complementary mnemonic “VFMADD312PD” in addition to the true 
mnemonic “VFMADD132PD*. The assembler will generate the same instruction opcode sequence corresponding to 
VFMADD132PD. The processor executes VFMADD132PD and report any NAN conditions based on the definition of 
VFMADD132PD. Similarly, if the complementary mnemonic VFMADD123PD is supported by an assembler at source 
level, it must generate the opcode sequence corresponding to VFMADD213PD; the complementary mnemonic 
VFMADD321PD must produce the opcode sequence defined by VFMADD231PD. In the absence of FMA operations 
reporting a NAN result, the numerical results of using either mnemonic with an assembler supporting both 
mnemonics will match the behavior defined in Table 14-17. Support for the complementary FMA mnemonics by 
software tools is optional. 


14.5.2 Fused-Multiply-ADD (FMA) Numeric Behavior 


FMA instructions can perform fused-multiply-add operations (including fused-multiply-subtract, and other vari- 
eties) on packed and scalar data elements in the instruction operands. Separate FMA instructions are provided to 
handle different types of arithmetic operations on the three source operands. 


FMA instruction syntax is defined using three source operands and the first source operand is updated based on the 
result of the arithmetic operations of the data elements of 128-bit or 256-bit operands, i.e. The first source operand 
is also the destination operand. 


The arithmetic FMA operation performed in an FMA instruction takes one of several forms, r=(x*y)+z, r=(x*y)-z, 
r=-(x*y)+z, or r=-(x*y)-z. Packed FMA instructions can perform eight single-precision FMA operations or four 
double-precision FMA operations with 256-bit vectors. 


Scalar FMA instructions only perform one arithmetic operation on the low order data element. The content of the 
rest of the data elements in the lower 128-bits of the destination operand is preserved. the upper 128bits of the 
destination operand are filled with zero. 
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An arithmetic FMA operation of the form, r=(x*y)+z, takes two IEEE-754-2008 single (double) precision values 
and multiplies them to form an infinite precision intermediate value. This intermediate value is added to a third 
single (double) precision value (also at infinite precision) and rounded to produce a single (double) precision result. 


Table 14-17 describes the numerical behavior of the FMA operation, r=(x*y)+z, r=(x*y)-z, r=-(x*y)+z, r=-(x*y)- 
z for various input values. The input values can be 0, finite non-zero (F in Table 14-17), infinity of either sign (INF 
in Table 14-17), positive infinity (+INF in Table 14-17), negative infinity (-INF in Table 14-17), or NaN (including 
QNaN or SNaN). If any one of the input values is a NAN, the result of FMA operation, r, may be a quietized NAN. The 
result can be either Q(x), Q(y), or Q(z), see Table 14-17. If x is a NaN, then: 


* Q(x) = x if x is QNaN or 
* Q(x) = the quietized NaN obtained from x if x is SNaN 
The notation for the output value in Table 14-17 are: 


¢ “+INF": positive infinity, “-INF”: negative infinity. When the result depends on a conditional expression, both 
values are listed in the result column and the condition is described in the comment column. 


° QNaNIndefinite represents the QNaN which has the sign bit equal to 1, the most significand field equal to 1, and 
the remaining significand field bits equal to 0. 


¢ The summation or subtraction of Os or identical values in FMA operation can lead to the following situations 
shown in Table 14-16 


¢ If the FMA computation represents an invalid operation (e.g. when adding two INF with opposite signs)), the 
invalid exception is signaled, and the MXCSR.IE flag is set. 


Table 14-16. Rounding Behavior of Zero Result in FMA Operation 


x*y z (x*y) +z (x*y) -z -(x*y) +z - (x*y)-z 
(+0) | (+0) +0 in all rounding modes - 0 when rounding down, - 0 when rounding down, - 0 in all rounding modes 
and +0 otherwise and +0 otherwise 
(+0) (-0) | O when rounding down, +0 in all rounding modes - 0 in all rounding modes - 0 when rounding down, 
and +0 otherwise and +0 otherwise 
(-0) (+0) | 2 O when rounding down, - 0 in all rounding modes + 0 in all rounding modes - 0 when rounding down, 
and +0 otherwise and +0 otherwise 
(-0) (0) | 0 in all rounding modes - 0 when rounding down, - 0 when rounding down, + 0 in all rounding modes 
and +0 otherwise and +0 otherwise 
E ec - 0 when rounding down, 2*F -2*F - 0 when rounding down, 
and +0 otherwise and +0 otherwise 
E E 2*F - 0 when rounding down, - 0 when rounding down, -2*F 
and +0 otherwise and +0 otherwise 
Table 14-17. FMA Numeric Behavior 
Xx y r=(x*y) | r=(x*y) r= i 
(multiplicand) | (multiplier) £ +Z -Z -(x*y)+z | -(x*y)-z Comment 
NaN O, F, INF, 0,F, | Q(x) Q(x) Q(x) Q(x) Signal invalid exception if x or y or z is SNaN 
NaN INF, 
NaN 
O, F, INF NaN 0,F, | Q(y) Q(y) Q(y) Q(y) Signal invalid exception if y or z is SNaN 
INF, 
NaN 
O, F, INF O, F, INF NaN | Q(z) Q(z) Q(z) Q(z) Signal invalid exception if z is SNaN 
INF F, INF +IN +INF QNaNIn | QNaNind | -INF if x*y and z have the same sign 
F definite | efinite 
QNaNIn -INF +INF QNaNind | if x*y and z have opposite signs 
definite efinite 
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X y r=(x*y) | r=(x*y) r= r= 
(multiplicand) | (multiplier) : +Z -Z -(x*y)+z | -(x*y)-z Comment 
INF F, INF -INF | -INF QNaNIn | QNaNind | +INF if x*y and z have the same sign 
definite | efinite 
QNaNIn +INF -INF QNaNind | if x*y and z have opposite signs 
definite efinite 
INF F, INF 0,F | +INF +INF -INF -INF if x and y have the same sign 
-INF -INF +INF +INF if x and y have opposite signs 
INF 0) 0,F, | QNaNIn | QNaNIn | QNaNiInd | QNaNind | Signal invalid exception 
INF definite | definite | efinite efinite 
0) INF 0,F, | QNaNIn | QNaNIn | QNaNiInd | QNaNind | Signal invalid exception 
INF definite | definite | efinite efinite 
F INF +IN | +INF QNaNIn | QNaNind | -INF if x*y and z have the same sign 
F definite | efinite 
QNaNin_ | -INF +INF if x*y and z have opposite signs 
definite QNaNiInd 
efinite 
F INF -INF | -INF QNaNIn | QNaNind | +INF if x*y and z have the same sign 
definite | efinite 
QNaNIn | +INF -INF QNaNind | if x*y and z have opposite signs 
definite efinite 
F INF 0,F +INF +INF -INF -INF ifx*y>O 
-INF -INF +INF +INF ifx*y<O 
0,F OF INF +INF -INF +INF -INF ifz>0 
-INF +INF -INF +INF ifz<0 
0 0 0 0 0 0 0 The sign of the result depends on the sign of 
0 F 0 0 0 0 0 the operands and on the rounding mode. The 
c 0 0 0 0 0 0 product x*y is +0 or -0, depending on the signs 
of x and y. The summation/subtraction of the 
zero representing (x*y) and the zero represent- 
ing z can lead to one of the four cases shown in 
Table 14-16. 
0 0 F z -Z z -Z 
0 F F z -2 z -2 
F 0 F -2 z -2 
F F 0 x*y x*y -x*y -x*y Rounded to the destination precision, with 
bounded exponent 
F F F (x*y)+z | (x*y)-z -(x*y)+zZ | -(x*y)-z Rounded to the destination precision, with 
bounded exponent; however, if the exact values 
of x*y and z are equal in magnitude with signs 
resulting in the FMA operation producing O, the 
rounding behavior described in Table 14-16. 


If unmasked floating-point exceptions are signaled (invalid operation, denormal operand, overflow, underflow, or 
inexact result) the result register is left unchanged and a floating-point exception handler is invoked. 


14.5.3 Detection of FMA 
Hardware support for FMA is indicated by CPUID.1:ECX.FMA[bit 12]=1. 


Application Software must identify that hardware supports AVX, after that it must also detect support for FMA by 
CPUID.1:ECX.FMA[bit 12]. The recommended pseudocode sequence for detection of FMA is: 
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INT supports_fma() 
{ ; result in eax 
mov eax, 1 
cpuid 
and ecx, 018001000H 
cmp ecx, 018001000H; check OSXSAVE, AVX, FMA feature flags 
jne not_supported 
; processor supports AVX,FMA instructions and XGETBV is enabled by OS 
mov ecx, 0; specify 0 for XCRO register 
XGETBV; result in EDX:EAX 
and eax, 06H 
cmp eax, 06H; check OS has enabled both XMM and YMM state support 
jne not_supported 
mov eax, 1 
jmp done 
NOT_SUPPORTED: 
mov eax, 0 
done: 


Note that FMA comprises 256-bit and 128-bit SIMD instructions operating on YMM states. 


14.6 OVERVIEW OF INTEL® ADVANCED VECTOR EXTENSIONS 2 (INTEL® AVX2) 


Intel® AVX2 extends Intel AVX by promoting most of the 128-bit SIMD integer instructions with 256-bit numeric 
processing capabilities. AVX2 instructions follow the same programming model as AVX instructions. 


In addition, AVX2 provide enhanced functionalities for broadcast/permute operations on data elements, vector 
shift instructions with variable-shift count per data element, and instructions to fetch non-contiguous data 
elements from memory. 


14.6.1. AVX2 and 256-bit Vector Integer Processing 


AVX2 promotes the vast majority of 128-bit integer SIMD instruction sets to operate with 256-bit wide YMM regis- 
ters. AVX2 instructions are encoded using the VEX prefix and require the same operating system support as AVX. 
Generally, most of the promoted 256-bit vector integer instructions follow the 128-bit lane operation, similar to the 
promoted 256-bit floating-point SIMD instructions in AVX. 


Newer functionalities in AVX2 generally fall into the following categories: 


¢ Fetching non-contiguous data elements from memory using vector-index memory addressing. These “gather” 
instructions introduce a new memory-addressing form, consisting of a base register and multiple indices 
specified by a vector register (either XMM or YMM). Data elements sizes of 32 and 64-bits are supported, and 
data types for floating-point and integer elements are also supported. 


* Cross-lane functionalities are provided with several new instructions for broadcast and permute operations. 
Some of the 256-bit vector integer instructions promoted from legacy SSE instruction sets also exhibit cross- 
lane behavior, e.g. VPMOVZ/VPMOVS family. 


¢ AVX2 complements the AVX instructions that are typed for floating-point operation with a full compliment of 
equivalent set for operating with 32/64-bit integer data elements. 
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¢ Vector shift instructions with per-element shift count. Data elements sizes of 32 and 64-bits are supported. 


14.7. PROMOTED VECTOR INTEGER INSTRUCTIONS IN AVX2 


In AVX2, most SSE/SSE2/SSE3/SSSE3/SSE4 vector integer instructions have been promoted to support VEX.256 
encodings. Table 14-18 summarizes the promotion status for existing instructions. The column “VEX.128” indicates 
whether the instruction using VEX.128 prefix encoding is supported. 


The column “VEX.256” indicates whether 256-bit vector form of the instruction using the VEX.256 prefix encoding 
is supported, and under which feature flag. 


Table 14-18. Promoted Vector Integer SIMD Instructions in AVX2 


VEX.256 Encoding VEX.128 Encoding Group Instruction 
AVX2 AVX YY OF 6X PUNPCKLBW 
AVX2 AVX PUNPCKLWD 
AVX2 AVX PUNPCKLDQ 
AVX2 AVX PACKSSWB 
AVX2 AVX PCMPGTB 
AVX2 AVX PCMPGTW 
AVX2 AVX PCMPGTD 
AVX2 AVX PACKUSWB 
AVX2 AVX PUNPCKHBW 
AVX2 AVX PUNPCKHWD 
AVX2 AVX PUNPCKHDQ 
AVX2 AVX PACKSSDW 
AVX2 AVX PUNPCKLQDQ 
AVX2 AVX PUNPCKHQDQ 
no AVX MOVD 

no AVX MOVQ 

AVX AVX MOVDQA 
AVX AVX MOVDQU 
AVX2 AVX YY OF 7X PSHUFD 
AVX2 AVX PSHUFHW 
AVX2 AVX PSHUFLW 
AVX2 AVX PCMPEQB 
AVX2 AVX PCMPEQW 
AVX2 AVX PCMPEQD 
AVX AVX MOVDQA 
AVX AVX MOVDQU 

no AVX PINSRW 

no AVX PEXTRW 
AVX2 AVX PSRLW 
AVX2 AVX PSRLD 
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Table 14-18. Promoted Vector Integer SIMD Instructions in AVX2 


VEX.256 Encoding VEX.128 Encoding Group Instruction 
AVX2 AVX PSRLQ 
AVX2 AVX PADDQ 
AVX2 AVX PMULLW 
AVX2 AVX PMOVMSKB 
AVX2 AVX PSUBUSB 
AVX2 AVX PSUBUSW 
AVX2 AVX PMINUB 
AVX2 AVX PAND 
AVX2 AVX PADDUSB 
AVX2 AVX PADDUSW 
AVX2 AVX PMAXUB 
AVX2 AVX PANDN 
AVX2 AVX YY OF EX PAVGB 
AVX2 AVX PSRAW 
AVX2 AVX PSRAD 
AVX2 AVX PAVGW 
AVX2 AVX PMULHUW 
AVX2 AVX PMULHW 
AVX AVX MOVNTDQ 
AVX2 AVX PSUBSB 
AVX2 AVX PSUBSW 
AVX2 AVX PMINSW 
AVX2 AVX POR 

AVX2 AVX PADDSB 
AVX2 AVX PADDSW 
AVX2 AVX PMAXSW 
AVX2 AVX PXOR 
AVX AVX YY OF FX LDDQU 
AVX2 AVX PSLLW 
AVX2 AVX PSLLD 
AVX2 AVX PSLLQ 
AVX2 AVX PMULUDQ 
AVX2 AVX PMADDWD 
AVX2 AVX PSADBW 
AVX2 AVX PSUBB 
AVX2 AVX PSUBW 
AVX2 AVX PSUBD 
AVX2 AVX PSUBQ 
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Table 14-18. Promoted Vector Integer SIMD Instructions in AVX2 


VEX.256 Encoding VEX.128 Encoding Group Instruction 
AVX2 AVX PADDB 
AVX2 AVX PADDW 
AVX2 AVX PADDD 
AVX2 AVX SSSE3 PHADDW 
AVX2 AVX PHADDSW 
AVX2 AVX PHADDD 
AVX2 AVX PHSUBW 
AVX2 AVX PHSUBSW 
AVX2 AVX PHSUBD 
AVX2 AVX PMADDUBSW 
AVX2 AVX PALIGNR 
AVX2 AVX PSHUFB 
AVX2 AVX PMULHRSW 
AVX2 AVX PSIGNB 
AVX2 AVX PSIGNW 
AVX2 AVX PSIGND 
AVX2 AVX PABSB 
AVX2 AVX PABSW 
AVX2 AVX PABSD 
AVX2 AVX MOVNTDQA 
AVX2 AVX MPSADBW 
AVX2 AVX PACKUSDW 
AVX2 AVX PBLENDVB 
AVX2 AVX PBLENDW 
AVX2 AVX PCMPEQQ 
no AVX PEXTRD 

no AVX PEXTRQ 

no AVX PEXTRB 

no AVX PEXTRW 

no AVX PHMINPOSUW 
no AVX PINSRB 

no AVX PINSRD 

no AVX PINSRQ 
AVX2 AVX PMAXSB 
AVX2 AVX PMAXSD 
AVX2 AVX PMAXUD 
AVX2 AVX PMAXUW 
AVX2 AVX PMINSB 
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Table 14-18. Promoted Vector Integer SIMD Instructions in AVX2 


VEX.256 Encoding VEX.128 Encoding Group Instruction 
AVX2 AVX PMINSD 
AVX2 AVX PMINUD 
AVX2 AVX PMINUW 
AVX2 AVX PMOVSXxx 
AVX2 AVX PMOVZXxx 
AVX2 AVX PMULDQ 
AVX2 AVX PMULLD 
AVX AVX PTEST 

AVX2 AVX SSE4.2 PCMPGTQ 

no AVX PCMPESTRI 
no AVX PCMPESTRM 
no AVX PCMPISTRI 
no AVX PCMPISTRM 
no AVX AESNI AESDEC 

no AVX AESDECLAST 
no AVX AESENC 

no AVX AESECNLAST 
no AVX AESIMC 

no AVX AESKEYGENASSIST 
no AVX CLMUL PCLMULQDQ 


Table 14-19 compares complementary SIMD functionalities introduced in AVX and AVX2. instructions. 


Table 14-19. VEX-Only SIMD Instructions in AVX and AVX2 


AVX2 AVX Comment 
VBROADCASTI128 VBROADCASTF128 256-bit only 
VBROADCASTSD ymm1, xmm VBROADCASTSD ymm1, m64 256-bit only 
VBROADCASTSS (from xmm) VBROADCASTSS (from m32) 
VEXTRACTI128 VEXTRACTF128 256-bit only 
VINSERTI128 VINSERTF128 256-bit only 
VPMASKMOVD VMASKMOVPS 
VPMASKMOVQ! VMASKMOVPD 
VPERMILPD in-lane 
VPERMILPS in-lane 
VPERM21128 VPERM2F128 256-bit only 
VPERMD cross-lane 
VPERMPS cross-lane 
VPERMQ cross-lane 
VPERMPD cross-lane 
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Table 14-19. VEX-Only SIMD Instructions in AVX and AVX2 


AVX2 AVX Comment 
VTESTPD 
VTESTPS 
VPBLENDD 
VPSLLVD/Q 
VPSRAVD 
VPSRLVD/Q 
VGATHERDPD/QPD 
VGATHERDPS/QPS 
VPGATHERDD/QD 
VPGATHERDQ/QQ 
Table 14-20. New Primitive in AVX2 Instructions 
Instruction Description 


VPERMD ymm1, ymm2, ymm3/m256 


Permute doublewords in ymm3/m256 using indexes in ymm_2 and store the result in ymm1. 


VPERMPD ymm1, ymm2/m256, imm8 


Permute double-precision FP elements in ymm2/m256 using indexes in imm8 and store the 
result in ymm1. 


VPERMPS ymm1, ymm2, ymm3/m256 


Permute single-precision FP elements in ymm3/m256 using indexes in ymm2 and store the 
result in ymm1. 


VPERMQ ymm1, ymm2/m256, imm8 


Permute quadwords in ymm2/m256 using indexes in imm8 and store the result in ymm1. 


VPSLLVD xmm1, xmm2, xmm3/m128 


Shift doublewords in xmm2 left by amount specified in the corresponding element of 
xmm3/m128 while shifting in Os. 


VPSLLVQ xmm1, xmm2, xmm3/m128 


Shift quadwords in xmm2 left by amount specified in the corresponding element of 
xmm3/m128 while shifting in Os. 


VPSLLVD ymm1, ymm2, ymm3/m256 


Shift doublewords in ymm2 left by amount specified in the corresponding element of 
ymm3/m256 while shifting in Os. 


VPSLLVQ ymm1, ymm2, ymm3/m256 


Shift quadwords in ymm2 left by amount specified in the corresponding element of 
ymm3/m256 while shifting in Os. 


VPSRAVD xmm1, xmm2, xmm3/m128 


Shift doublewords in xmm2 right by amount specified in the corresponding element of 
xmm3/m128 while shifting in the sign bits. 


VPSRLVD xmm1, xmm2, xmm3/m128 


Shift doublewords in xmm2 right by amount specified in the corresponding element of 
xmm3/m128 while shifting in Os. 


VPSRLVQ xmm1, xmm2, xmm3/m128 


Shift quadwords in xmm_2 right by amount specified in the corresponding element of 
xmm3/m128 while shifting in Os. 


VPSRLVD ymm1, ymm2, ymm3/m256 


Shift doublewords in ymm2 right by amount specified in the corresponding element of 
ymm3/m256 while shifting in Os. 


VPSRLVQ ymm1, ymm2, ymm3/m256 


Shift quadwords in ymm2 right by amount specified in the corresponding element of 
ymm3/m256 while shifting in Os. 


VGATHERDD xmm1, vm32x, xmm2 


Using dword indices specified in vm32x, gather dword values from memory conditioned on 
mask specified by xmm2. Conditionally gathered elements are merged into xmm1. 


VGATHERQD xmm1, vm64x, xmm2 


Using qword indices specified in vm64x, gather dword values from memory conditioned on 
mask specified by xmm2. Conditionally gathered elements are merged into xmm1. 


VGATHERDD ymm1, vm32y, ymm2 


Using dword indices specified in vm32y, gather dword values from memory conditioned on 
mask specified by ymm2. Conditionally gathered elements are merged into ymm1. 


VGATHERQD ymm1, vm64y, ymm2 


Using qword indices specified in vm64y, gather dword values from memory conditioned on 
mask specified by ymm2. Conditionally gathered elements are merged into ymm1. 


14-30 Vol. 1 


PROGRAMMING WITH AVX, FMA AND AVX2 


Instruction Description 


VGATHERDPD xmm1, vm32x, xmm2 Using dword indices specified in vm32x, gather double-precision FP values from memory 
conditioned on mask specified by xmm2. Conditionally gathered elements are merged into 
xmm1. 


VGATHERQPD xmm1, vm64x, xmm2 Using qword indices specified in vm64x, gather double-precision FP values from memory 
conditioned on mask specified by xmm2. Conditionally gathered elements are merged into 
xmm1. 


VGATHERDPD ymm1, vm32x, ymm2 Using dword indices specified in vm32x, gather double-precision FP values from memory 
conditioned on mask specified by ymm2. Conditionally gathered elements are merged into 
ymm1. 


VGATHERQPD ymm1, vm64y ymm2 Using qword indices specified in vm64y, gather double-precision FP values from memory 
conditioned on mask specified by ymm2. Conditionally gathered elements are merged into 
ymm1. 


VGATHERDPS xmm1, vm32x, xmm2 Using dword indices specified in vm32x, gather single-precision FP values from memory 
conditioned on mask specified by xmm2. Conditionally gathered elements are merged into 
xmm1. 


VGATHEROPS xmm1, vm64x, xmm2 Using qword indices specified in vm64x, gather single-precision FP values from memory 
conditioned on mask specified by xmm2. Conditionally gathered elements are merged into 
xmm1. 


VGATHERDPS ymm1, vm32y, ymm2 Using dword indices specified in vm32y, gather single-precision FP values from memory 
conditioned on mask specified by ymm2. Conditionally gathered elements are merged into 
ymm1. 


VGATHEROPS xmm1, vm64y, xmm2 Using qword indices specified in vm64y, gather single-precision FP values from memory 
conditioned on mask specified by xmm2. Conditionally gathered elements are merged into 


xmm1. 
VGATHERDQ xmm1, vm32x, xmm2 Using dword indices specified in vm32x, gather qword values from memory conditioned on 
mask specified by xmm2. Conditionally gathered elements are merged into xmm1. 
VGATHERQQ xmm1, vm64x, xmm2 Using qword indices specified in vm64x, gather qword values from memory conditioned on 
mask specified by xmm2. Conditionally gathered elements are merged into xmm1. 
VGATHERDQ ymm1, vm32x, ymm2 Using dword indices specified in vm32x, gather qword values from memory conditioned on 
mask specified by ymm2. Conditionally gathered elements are merged into ymm1. 
VGATHERQQ ymm1, vm64y, ymm2 Using qword indices specified in vm64y, gather qword values from memory conditioned on 


mask specified by ymm2. Conditionally gathered elements are merged into ymm1. 


14.7.1 Detection of AVX2 
Hardware support for AVX2 is indicated by CPUID.(EAX=07H, ECX=0H):EBX.AVX2[bit 5]=1. 


Application Software must identify that hardware supports AVX, after that it must also detect support for AVX2 by 
checking CPUID.(EAX=07H, ECX=0H):EBX.AVX2[bit 5]. The recommended pseudocode sequence for detection of 
AVX2 is: 


INT supports_avx2() 
{ ; result in eax 
mov eax, 1 
cpuid 
and ecx, 018000000H 
cmp ecx, 018000000H; check both OSXSAVE and AVX feature flags 
jne not_supported 
; processor supports AVX instructions and XGETBV is enabled by OS 
mov eax, 7 
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mov ecx, 0 

cpuid 

and ebx, 20H 

cmp ebx, 20H; check AVX2 feature flags 
jne not_supported 

mov ecx, 0; specify 0 for XCRO register 
XGETBV; result in EDX:EAX 

and eax, 06H 

cmp eax, 06H; check OS has enabled both XMM and YMM state support 
jne not_supported 

mov eax, 1 

jmp done 

NOT_SUPPORTED: 

mov eax, 0 

done: 


14.8 ACCESSING YMM REGISTERS 


The lower 128 bits of a YMM register is aliased to the corresponding XMM register. Legacy SSE instructions (i.e. 
SIMD instructions operating on XMM state but not using the VEX prefix, also referred to non-VEX encoded SIMD 
instructions) will not access the upper bits (255:128) of the YMM registers. AVX and FMA instructions with a VEX 
prefix and vector length of 128-bits zeroes the upper 128 bits of the YMM register. 


Upper bits of YMM registers (255:128) can be read and written by many instructions with a VEX.256 prefix. 
XSAVE and XRSTOR may be used to save and restore the upper bits of the YMM registers. 


14.9 MEMORY ALIGNMENT 


Memory alignment requirements on VEX-encoded instruction differs from non-VEX-encoded instructions. Memory 
alignment applies to non-VEX-encoded SIMD instructions in three categories: 


° Explicitly-aligned SIMD load and store instructions accessing 16 bytes of memory (e.g. MOVAPD, MOVAPS, 
MOVDQA, etc.). These instructions always require memory address to be aligned on 16-byte boundary. 


°  Explicitly-unaligned SIMD load and store instructions accessing 16 bytes or less of data from memory (e.g. 
MOVUPD, MOVUPS, MOVDQU, MOVQ, MOVD, etc.). These instructions do not require memory address to be 
aligned on 16-byte boundary. 


¢ The vast majority of arithmetic and data processing instructions in legacy SSE instructions (non-VEX-encoded 
SIMD instructions) support memory access semantics. When these instructions access 16 bytes of data from 
memory, the memory address must be aligned on 16-byte boundary. 


Most arithmetic and data processing instructions encoded using the VEX prefix and performing memory accesses 

have more flexible memory alignment requirements than instructions that are encoded without the VEX prefix. 

Specifically, 

¢ With the exception of explicitly aligned 16 or 32 byte SIMD load/store instructions, most VEX-encoded, 
arithmetic and data processing instructions operate in a flexible environment regarding memory address 
alignment, i.e. VEX-encoded instruction with 32-byte or 16-byte load semantics will support unaligned load 
operation by default. Memory arguments for most instructions with VEX prefix operate normally without 
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causing #GP(0) on any byte-granularity alignment (unlike Legacy SSE instructions). The instructions that 
require explicit memory alignment requirements are listed in Table 14-22. 


Software may see performance penalties when unaligned accesses cross cacheline boundaries, so reasonable 
attempts to align commonly used data sets should continue to be pursued. 


Atomic memory operation in Intel 64 and IA-32 architecture is guaranteed only for a subset of memory operand 
sizes and alignment scenarios. The list of guaranteed atomic operations are described in Section 8.1.1 of IA-32 
Intel® Architecture Software Developer’s Manual, Volumes 3A. AVX and FMA instructions do not introduce any new 
guaranteed atomic memory operations. 


AVX instructions can generate an #AC(0) fault on misaligned 4 or 8-byte memory references in Ring-3 when 
CRO.AM=1. 16 and 32-byte memory references will not generate #AC(0) fault. See Table 14-21 for details. 


Certain AVX instructions always require 16- or 32-byte alignment (see the complete list of such instructions in 
Table 14-22). These instructions will #GP(0) if not aligned to 16-byte boundaries (for 16-byte granularity loads and 
stores) or 32-byte boundaries (for 32-byte loads and stores). 


Table 14-21. Alignment Faulting Conditions when Memory Access is Not Aligned 


EFLAGS.AC==1 && Ring-3 && CRO.AM == 1 0 1 
a “explicitly unaligned” loads and stores (see Table aartatilt ao faut 
= VEX op YMM, m256 no fault no fault 
2. x VEX op XMM, m128 no fault no fault 
- — “explicitly aligned” loads and stores (see Table 14-22) #GP(0) #GP(0) 
is 2, 4, or 8-byte loads and stores no fault #AC(0) 
5 16 byte “explicitly unaligned” loads and stores (see Table 14-23) no fault no fault 
a ‘a op XMM, m128 #GP(0) #GP(0) 
a “explicitly aligned” loads and stores (see Table 14-22) #GP(0) #GP(0) 
2, 4, or 8-byte loads and stores no fault #AC(0) 


Table 14-22. Instructions Requiring Explicitly Aligned Memory 
Require 16-byte alignment 


Require 32-byte alignment 


(V)MOVDQA xmm, m128 


VMOVDQA ymm, m256 


(V)MOVDQA m128, xmm 


VMOVDQA m256, ymm 


V)MOVAPS xmm, m128 


VMOVAPS ymm, m256 


( 
(V)MOVAPS m1 28, xmm 


VMOVAPS m256, ymm 
VMOVAPD ymm, m256 


) 
) 

V)MOVAPD xmm, m128 
) 


( 
(V)MOVAPD m128, xmm 


VMOVAPD m256, ymm 


(V)MOVNTPS m128, xmm 
(V)MOVNTPD m128, xmm 


VMOVNTPS m256, ymm 
VMOVNTPD m256, ymm 


(V)MOVNTDQ m128, xmm 


VMOVNTDQ m256, ymm 


(V)MOVNTDOA xmm, m128 


VMOVNTDQA ymm, m256 
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Table 14-23. Instructions Not Requiring Explicit Memory Alignment 
(V)MOVDQU xmm, m128 
(V)MOVDQU m128, m128 
(V)MOVUPS xmm, m128 
(V)MOVUPS m128, xmm 
(V)MOVUPD xmm, m128 
(V)MOVUPD m128, xmm 

VMOVDQU ymm, m256 
VMOVDQU m256, ymm 
VMOVUPS ymm, m256 
VMOVUPS m256, ymm 
VMOVUPD ymm, m256 
VMOVUPD m256, ymm 


14.10 SIMD FLOATING-POINT EXCEPTIONS 


AVX instructions can generate SIMD floating-point exceptions (#XM) and respond to exception masks in the same 
way as Legacy SSE instructions. When CR4.0SXMMEXCPT=0 any unmasked FP exceptions generate an Undefined 
Opcode exception (#UD). 

AVX FP exceptions are created in a similar fashion (differing only in number of elements) to Legacy SSE and SSE2 
instructions capable of generating SIMD floating-point exceptions. 

AVX introduces no new arithmetic operations (AVX floating-point are analogues of existing Legacy SSE instruc- 
tions). 

F16C, FMA instructions can generate SIMD floating-point exceptions (#XM). The requirement that apply to AVX 
also apply to F16C and FMA. 

The subset of AVX2 instructions that operate on floating-point data do not generate #XM. 


The detailed exception conditions for AVX instructions and legacy SIMD instructions (excluding instructions that 
operates on MMX registers) are described in a number of exception class types, depending on the operand syntax 
and memory operation characteristics. The complete list of SIMD instruction exception class types are defined in 
Chapter 2, “Instruction Format,” of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A. 


14.11 EMULATION 


Setting the CRO.EMbit to 1 provides a technique to emulate Legacy SSE floating-point instruction sets in software. 
This technique is not supported with AVX instructions. 


If an operating system wishes to emulate AVX instructions, set XCRO[2:1] to zero. This will cause AVX instructions 
to #UD. Emulation of F16C, AVX2, and FMA by operating system can be done similarly as with emulating AVX 
instructions. 


14.12 WRITING AVX FLOATING-POINT EXCEPTION HANDLERS 


AVX and FMA floating-point exceptions are handled in an entirely analogous way to Legacy SSE floating-point 
exceptions. To handle unmasked SIMD floating-point exceptions, the operating system or executive must provide 
an exception handler. The section titled “SSE and SSE2 SIMD Floating-Point Exceptions” in Chapter 11, “Program- 
ming with Streaming SIMD Extensions 2 (SSE2),” describes the SIMD floating-point exception classes and gives 
suggestions for writing an exception handler to handle them. 
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To indicate that the operating system provides a handler for SIMD floating-point exceptions (#XM), the CR4.0SXM- 
MEXCPT flag (bit 10) must be set. 


The guidelines for writing AVX floating-point exception handlers also apply to F16C and FMA. 


14.13 GENERAL PURPOSE INSTRUCTION SET ENHANCEMENTS 


Enhancements in the general-purpose instruction set consist of several categories: 


¢ = Arich collection of instructions to manipulate integer data at bit-granularity. Most of the bit-manipulation 
instructions employ VEX-prefix encoding to support three-operand syntax with non-destructive source 
operands. Two of the bit-manipulating instructions (LZCNT, TZCNT) are not encoded using VEX. The VEX- 
encoded bit-manipulation instructions include: ANDN, BEXTR, BLSI, BLSMSK, BLSR, BZHI, PEXT, PDEP, SARX, 
SHLX, SHRX, and RORX. 


¢ Enhanced integer multiply instruction (MULX) in conjunctions with some of the bit-manipulation instructions 
allow software to accelerate calculation of large integer numerics (wider than 128-bits). 


¢ INVPCID instruction targets system software that manages processor context IDs. 
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PROGRAMMING WITH INTEL® AVX-512 


15.1 OVERVIEW 


The Intel AVX-512 family comprises a collection of instruction set extensions, including AVX-512 Foundation, 
AVX-512 Exponential and Reciprocal instructions, AVX-512 Conflict, AVX-512 Prefetch, and additional 512-bit 
SIMD instruction extensions. Intel AVX-512 instructions are natural extensions to Intel AVX and Intel AVX2. Intel 
AVX-512 introduces the following architectural enhancements: 

* Support for 512-bit wide vectors and SIMD register set. 512-bit register state is managed by the operating 
system using XSAVE/XRSTOR instructions introduced in 45 nm Intel 64 processors (see Inte/® 64 and IA-32 
Architectures Software Developer’s Manual, Volume 2B, and Intel® 64 and IA-32 Architectures Software 
Developer’s Manual, Volume 3A). 

* Support for 16 new, 512-bit SIMD registers (for a total of 32 SIMD registers, ZMMO through ZMM31) in 64-bit 
mode. The extra 16 registers state is managed by the operating system using XSAVE/XRSTOR/XSAVEOPT. 

¢ Support for 8 new opmask registers (kO through k7) used for conditional execution and efficient merging of 
destination operands. The opmask register state is managed by the operating system using the 
XSAVE/XRSTOR/XSAVEOPT instructions. 

¢ Anew encoding prefix (referred to as EVEX) to support additional vector length encoding up to 512 bits. The 
EVEX prefix builds upon the foundations of the VEX prefix to provide compact, efficient encoding for function- 
ality available to VEX encoding plus the following enhanced vector capabilities: 


¢ Opmasks. 

¢ Embedded broadcast. 

¢ Instruction prefix-embedded rounding control. 
* Compressed address displacements. 


15.1.1 512-Bit Wide SIMD Register Support 


Intel AVX-512 instructions support 512-bit wide SIMD registers (ZMMO-ZMM31). The lower 256-bits of the ZMM 
registers are aliased to the respective 256-bit YMM registers and the lower 128-bit are aliased to the respective 
128-bit XMM registers. 


15.1.2 32 SIMD Register Support 


Intel AVX-512 instructions also support 32 SIMD registers in 64-bit mode (XMMO-XMM31, YMMO-YMM31 and 
ZMMO-ZMM31). The number of available vector registers in 32-bit mode is still 8. 


15.1.3. Eight Opmask Register Support 


Intel AVX-512 instructions support 8 opmask registers (kO-k7). The width of each opmask register is architectur- 
ally defined as size MAX_KL (64 bits). Seven of the eight opmask registers (k1-k7) can be used in conjunction with 
EVEX-encoded AVX-512 Foundation instructions to provide conditional execution and efficient merging of data 
elements in the destination operand. The encoding of opmask register kO is typically used when all data elements 
(unconditional processing) are desired. Additionally, the opmask registers are also used as vector flags/element- 
level vector sources to introduce novel SIMD functionality as seen in new instructions such as VCOMPRESSPS. 
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Figure 15-1. 512-Bit Wide Vectors and SIMD Register Set 


15.1.4 — Instruction Syntax Enhancement 
The architecture of EVEX encoding enhances the vector instruction encoding scheme in the following way: 


¢ 512-bit vector-length, up to 32 ZMM registers, and enhanced vector programming environment are supported 
using the enhanced VEX (EVEX). 


The EVEX prefix provides more encodable bit fields than the VEX prefix. In addition to encoding 32 ZMM registers 
in 64-bit mode, instruction encoding using the EVEX prefix can directly encode 7 (out of 8) opmask register oper- 
ands to provide conditional processing in vector instruction programming. The enhanced vector programming envi- 
ronment can be explicitly expressed in the instruction syntax to include the following elements: 


¢ An opmask operand: the opmask registers are expressed using the notation “k1” through “k7”. An EVEX- 
encoded instruction supporting conditional vector operation using the opmask register k1 is expressed by 
attaching the notation {ki} next to the destination operand. The use of this feature is optional for most instruc- 
tions. There are two types of masking (merging and zeroing) differentiated using the EVEX.z bit ({z} in 
instruction signature). 


¢ Embedded broadcast may be supported for some instructions on the source operand that can be encoded as a 
memory vector. Data elements of a memory vector may be conditionally fetched or written to. 


¢ For instruction syntax that operates only on floating-point data in SIMD registers with rounding semantics, the 
EVEX encoding can provide explicit rounding control within the EVEX bit fields at either scalar or 512-bit vector 
length. 


In AVX-512 instructions, vector addition of all elements of the source operands can be expressed in the same 
syntax as AVX instruction: 


VADDPS zmm1l, zmm2, zmm3 

Additionally, the EVEX encoding scheme of AVX-512 Foundation can express conditional vector addition as: 
VADDPS zmm1 {k1}{z}, zmm2, zmm3 

where: 


* Conditional processing and updates to destination are expressed with an opmask register. 


¢ Zeroing behavior of the opmask selected destination element is expressed by the {z} modifier (with merging 
as the default if no modifier is specified). 
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Note that some SIMD instructions supporting three-operand syntax but processing only less than or equal to 128- 
bits of data are considered part of the 512-bit SIMD instruction set extensions, because bits MAXVL-1:128 of the 
destination register are zeroed by the processor. The same rule applies to instructions operating on 256-bits of data 
where bits MAXVL-1:256 of the destination register are zeroed. 


15.1.5 EVEX Instruction Encoding Support 


Intel AVX-512 instructions employ a new encoding prefix, referred to as EVEX, in the Intel 64 and IA-32 instruction 
encoding format. Instruction encoding using the EVEX prefix provides the following capabilities: 


* Direct encoding of a SIMD register operand within EVEX (similar to VEX). This provides instruction syntax 
support for three source operands. 


* Compaction of REX prefix functionality and extended SIMD register encoding: the equivalent REX-prefix 
compaction functionality offered by the VEX prefix is provided within EVEX. Furthermore, EVEX extends the 
operand encoding capability to allow direct addressing of up to 32 ZMM registers in 64-bit mode. 


* Compaction of SIMD prefix functionality and escape byte encoding: the functionality of a SIMD prefix (66H, 
F2H, F3H) on opcode is equivalent to an opcode extension field to introduce new processing primitives. This 
functionality is provided in the VEX prefix encoding scheme and employed within the EVEX prefix. Similarly, the 
functionality of the escape opcode byte (OFH) and two-byte escape (OF38H, OF3AH) are also compacted within 
the EVEX prefix encoding. 


¢ Most EVEX-encoded SIMD numeric and data processing instruction semantics with memory operands have 
more relaxed memory alignment requirements than instructions encoded using SIMD prefixes (see Section 
15.7, “Memory Alignment”). 


¢* Direct encoding of an opmask operand within the EVEX prefix. This provides instruction syntax support for 
conditional vector-element operation and merging of destination operand using an opmask register (ki-k7). 


¢ Direct encoding of a broadcast attribute for instructions with a memory operand source. This provides 
instruction syntax support for elements broadcasting the second operand before being used in the actual 
operation. 


¢ Compressed memory address displacements for a more compact instruction encoding byte sequence. 


EVEX encoding applies to SIMD instructions operating on XMM, YMM and ZMM registers. EVEX is not supported for 
instructions operating on MMX or x87 registers. Details of EVEX instruction encoding are discussed in Section 2.6, 
“Intel® AVX-512 Encoding” of the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A. 


15.2 DETECTION OF AVX-512 FOUNDATION INSTRUCTIONS 


The majority of AVX-512 Foundation instructions are encoded using the EVEX encoding scheme. EVEX-encoded 
instructions can operate on the 512-bit ZMM register state plus 8 opmask registers. The opmask instructions in 
AVX-512 Foundation instructions operate only on opmask registers or with a general purpose register. System 
software requirements to support the ZMM state and opmask instructions are described in Section 15.5, “Accessing 
XMM, YMM AND ZMM Registers”. 


Processor support of AVX-512 Foundation instructions is indicated by CPUID.(EAX=07H, ECX=0):EBX.AVX512F [bit 
16] = 1. Detection of AVX-512 Foundation instructions operating on ZMM states and opmask registers needs to 
follow the general procedural flow in Figure 15-2. 
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Figure 15-2. Procedural Flow for Application Detection of AVX-512 Foundation Instructions 


Prior to using AVX-512 Foundation instructions, the application must identify that the operating system supports 
the XGETBV instruction and the ZMM register state, in addition to confirming the processor’s support for ZMM state 
management using XSAVE/XRSTOR and AVX-512 Foundation instructions. The following simplified sequence 
accomplishes both and is strongly recommended. 


1. Detect CPUID.1:ECX.OSXSAVE[bit 27] = 1 (XGETBV enabled for application use’). 


2. Execute XGETBV and verify that XCRO[7:5] = ‘111b’ (OPMASK state, upper 256-bit of ZMMO-ZMM15 and 
ZMM16-ZMM31 state are enabled by OS) and that XCRO[2:1] =‘11b’ (XMM state and YMM state are enabled by 
OS). 


3. Detect CPUID.Ox7.0:EBX.AVX512F[bit 16] = 1. 


15.2.1 Additional 512-bit Instruction Extensions of the Intel AVX-512 Family 
Processor support of the Intel AVX-512 Exponential and Reciprocal instructions are indicated by querying the 
feature flag: 


e If CPUID.(EAX=07H, ECX=0):EBX.AVX512ER[bit 27] = 1, the collection of 
VEXP2PD/VEXP2PS/VRCP28xx/VRSQRT28xx instructions are supported. 


Processor support of the Intel AVX-512 Prefetch instructions are indicated by querying the feature flag: 


e If CPUID.(EAX=07H, ECX=0):EBX.AVX512PF[bit 26] = 1, a collection of 
VGATHERPFOxxx/VGATHERPF1xxx/VSCATTERPFOxxx/VSCATTERPF1xxx instructions are supported. 


Detection of 512-bit instructions operating on ZMM states and opmask registers, outside of AVX-512 Foundation, 
needs to follow the general procedural flow in Figure 15-3. 


1. If CPUID.01H:ECX.OSXSAVE reports 1, it also indirectly implies the processor supports XSAVE, XRSTOR, XGETBV, processor 
extended state bit vector XCRO register. Thus an application may streamline the checking of CPUID feature flags for XSAVE and OSX- 
SAVE. XSETBV is a privileged instruction. 
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Figure 15-3. Procedural Flow for Application Detection of 512-bit Instructions 


PREFETCHT1W does not require OS support for XMM/YMM/ZMM/k-reg, SIMD FP exception support. 
Procedural Flow of Application Detection of other 512-bit extensions: 


Prior to using the Intel AVX-512 Exponential and Reciprocal instructions, the application must identify that the 
operating system supports the XGETBV instruction and the ZMM register state, in addition to confirming the 
processor's support for ZMM state management using XSAVE/XRSTOR and AVX-512 Foundation instructions. The 
following simplified sequence accomplishes both and is strongly recommended. 


1. Detect CPUID.1:ECX.OSXSAVE[bit 27] = 1 (XGETBV enabled for application use). 


2. Execute XGETBV and verify that XCRO[7:5] = ‘111b’ (OPMASK state, upper 256-bit of ZMMO-ZMM15 and 
ZMM16-ZMM31 state are enabled by OS) and that XCRO[2:1] = ‘11b’ (XMM state and YMM state are enabled 
by OS). 

3. Verify both CPUID.0x7.0:EBX.AVX512F[bit 16] = 1, and CPUID.0x7.0:EBX.AVX512ER[bit 27] = 1. 

Prior to using the Intel AVX-512 Prefetch instructions, the application must identify that the operating system 

supports the XGETBV instruction and the ZMM register state, in addition to confirming the processor's support for 

ZMM state management using XSAVE/XRSTOR and AVX-512 Foundation instructions. The following simplified 

sequence accomplishes both and is strongly recommended. 


1. Detect CPUID.1:ECX.OSXSAVE[bit 27] = 1 (XGETBV enabled for application use). 


2. Execute XGETBV and verify that XCRO[7:5] = ‘111b’ (OPMASK state, upper 256-bit of ZMMO-ZMM15 and 
ZMM16-ZMM31 state are enabled by OS) and that XCRO[2:1] = ‘11b’ (XMM state and YMM state are enabled 
by OS). 


3. Verify both CPUID.Ox7.0:EBX.AVX512F[bit 16] = 1, and CPUID.Ox7.0:EBX.AVX512PF[bit 26] = 1. 


15.3. DETECTION OF 512-BIT INSTRUCTION GROUPS OF INTEL® AVX-512 
FAMILY 


In addition to the Intel AVX-512 Foundation instructions, Intel AVX-512 family provides several groups of instruc- 
tion extensions that can operate in vector lengths of 512/256/128 bits. Each group is enumerated by a CPUID leaf 
7 feature flag and can be encoded via the EVEX.L’L field to support operation at vector lengths smaller than 512 
bits. These instruction groups are listed in Table 15-1. 
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Table 15-1. 512-bit Instruction Groups in the Intel AVX-512 Family 


CPUID Leaf 7 Feature Flag Bit Feature Flag abbreviation of 512-bit Instruction Group SW Detection Flow 
CPUID.(EAX=07H, ECX=0):EBX[bit 16] AVX512F (AVX-512 Foundation) Figure 15-2 
CPUID.(EAX=07H, ECX=0):EBX[bit 28] AVX512CD Figure 15-4 
CPUID.(EAX=07H, ECX=0):EBX[bit 17] AVX512DQ Figure 15-4 
CPUID.(EAX=07H, ECX=0):EBX[bit 30] AVX512BW Figure 15-4 


Software must follow the detection procedure for the 512-bit AVX-512 Foundation instructions as described in 
Section 15.2. 


Detection of other 512-bit sibling instruction groups listed in Table 15-1 (excluding AVX512F) follows the procedure 
described in Figure 15-4: 


Check feature flag 
CPUID.1H:ECX.OXSAVE = 1? 


OS provides processor 
extended state management 


Yes Implied HW support for 
XSAVE, XRSTOR, XGETBV, XCRO 


Opmask, 
: YMM,ZMM 
Check enabled state in y Check AVX512F and 
XCRO via XGETBV States a sibling 512-bit flag ok to use 
enabled Instructions 


Figure 15-4. Procedural Flow for Application Detection of 512-bit Instruction Groups 


To detect 512-bit instructions enumerated by AVX512CD, the following sequence is strongly recommended. 
1. Detect CPUID.1:ECX.OSXSAVE[bit 27] = 1 (XGETBV enabled for application use). 


2. Execute XGETBV and verify that XCRO[7:5] = ‘111b’ (OPMASK state, upper 256-bit of ZMMO-ZMM15 and 
ZMM16-ZMM31 state are enabled by OS) and that XCRO[2:1] =‘11b’ (XMM state and YMM state are enabled by 
OS). 


3. Verify both CPUID.Ox7.0:EBX.AVX512F[bit 16] = 1, CPUID.Ox7.0:EBX.AVX512CD[bit 28] = 1. 


Similarly, the detection procedure for enumerating 512-bit instructions reported by AVX512DW follows the same 
flow. 


15.4 DETECTION OF INTEL AVX-512 INSTRUCTION GROUPS OPERATING AT 256 
AND 128-BIT VECTOR LENGTHS 


For each of the 512-bit instruction groups in the Intel AVX-512 family listed in Table 15-1, the EVEX encoding 
scheme may support a vast majority of these instructions operating at 256-bit or 128-bit (if applicable) vector 
lengths. Encoding support for vector lengths smaller than 512-bits is indicated by CPUID.(EAX=07H, 
ECX=0):EBX[bit 31], abbreviated as AVX512VL. 
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The AVX512VL flag alone is never sufficient to determine a given Intel AVX-512 instruction may be encoded at 
vector lengths smaller than 512 bits. Software must use the procedure described in Figure 15-5 and Table 15-2. 


Check feature flag 
CPUID.1H:ECX.OXSAVE = 1? 


OS provides processor 
extended state management 


Yes Implied HW support for 


XSAVE, XRSTOR, XGETBV, XCRO 


Opmask, 
; YMM,ZMM 
Check enabled statein | ye 
XCRO via XGETBV States 
enabled 


Check applicable collection of 
CPUID flags listed in Table 2-2 


ok to use 
Instructions 


Figure 15-5. Procedural Flow for Detection of Intel AVX-512 Instructions Operating at Vector Lengths < 512 


To illustrate the procedure described in Figure 15-5 and Table 15-2 for software to use EVEX.256 encoded VPCON- 


FLICT, the following sequence is provided. It is strongly recommended this sequence is followed. 


1) Detect CPUID.1:ECX.OSXSAVE[bit 27] = 1 (XGETBV enabled for application use). 


2) Execute XGETBV and verify that XCRO[7:5] = ‘111b’ (OPMASK state, upper 256-bit of ZMMO-ZMM15 and 
ZMM16-ZMM31 state are enabled by OS) and that XCRO[2:1] = ‘11b’ (XMM state and YMM state are enabled by 


OS). 


3) Verify CPUID.0x7.0:EBX.AVX512F[bit 16] = 1, CPUID.Ox7.0:EBX.AVX512CD[bit 28] = 1, and 


CPUID.0x7.0:EBX.AVX512VL[bit 31] = 1. 


Table 15-2. Feature flag Collection Required of 256/128 Bit Vector Lengths for Each Instruction Group 


Usage of 256/128 Vector Lengths 


Feature Flag Collection to Verify 


AVX512F 


AVX512F & AVX512VL 


AVX512CD 
AVX512DQ 


AVX512F & AVX512CD & AVX512VL 
AVX512F & AVX512DQ & AVX512VL 


AVX512BW 


AVX512F & AVX512BW & AVX512VL 


In some specific cases, AVX512VL may only support EVEX.256 encoding but not EVEX.128. These cases are listed 


in Table 15-3. 
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Table 15-3. Instruction Mnemonics That Do Not Support EVEX.128 Encoding 


Instruction Group Instruction Mnemonics Supporting EVEX.256 Only Using AVX512VL 
AVX512F VBROADCASTSD, VBROADCASTF32X4, VEXTRACTI32X4, VINSERTF32X4, VINSERTI32X4, VPERMD, 
VPERMPD, VPERMPS, VPERMQ, VSHUFF32X4, VSHUFF64X2, VSHUFI32X4, VSHUFI64X2 
AVX512CD 
AVX512D0 VBROADCASTF32X2, VBROADCASTF64X2, VBROADCASTI32X4, VBROADCASTI64X2, VEXTRACTI64X2, 
VINSERTF64X2, VINSERTI64X2, 
AVX512BW 


15.5 ACCESSING XMM, YMM AND ZMM REGISTERS 


The lower 128 bits of a YMM register is aliased to the corresponding XMM register. Legacy SSE instructions (i.e., 
SIMD instructions operating on XMM state but not using the VEX prefix, also referred to non-VEX encoded SIMD 
instructions) will not access the upper bits (MAXVL-1:128) of the YMM registers. AVX and FMA instructions with a 
VEX prefix and vector length of 128-bits zeroes the upper 128 bits of the YMM register. 


Upper bits of YMM registers (255:128) can be read and written to by many instructions with a VEX.256 prefix. 
XSAVE and XRSTOR may be used to save and restore the upper bits of the YMM registers. 

The lower 256 bits of a ZMM register are aliased to the corresponding YMM register. Legacy SSE instructions (i.e., 
SIMD instructions operating on XMM state but not using the VEX prefix, also referred to non-VEX encoded SIMD 
instructions) will not access the upper bits (MAXVL-1:128) of the ZMM registers, where MAXVL is maximum vector 
length (currently 512 bits). AVX and FMA instructions with a VEX prefix and vector length of 128-bits zero the upper 


384 bits of the ZMM register, while the VEX prefix and vector length of 256-bits zeroes the upper 256 bits of the 
ZMM register. 


Upper bits of ZMM registers (511:256) can be read and written to by instructions with an EVEX.512 prefix. 


15.6 ENHANCED VECTOR PROGRAMMING ENVIRONMENT USING EVEX 
ENCODING 


EVEX-encoded AVX-512 instructions support an enhanced vector programming environment. The enhanced vector 
programming environment uses the combination of EVEX bit-field encodings and a set of eight opmask registers to 
provide the following capabilities: 


* Conditional vector processing of an EVEX-encoded instruction. Opmask registers ki through k7 can be used to 
conditionally govern the per-data-element computational operation and the per-element updates to the 
destination operand of an AVX-512 Foundation instruction. Each bit of the opmask register governs one vector 
element operation (a vector element can be 8 bits, 16 bits, 32 bits or 64 bits). 


* In addition to providing predication control on vector instructions via EVEX bit-field encoding, the opmask 
registers can also be used similarly on general-purpose registers as source/destination operands using modR/M 
encoding for non-mask-related instructions. In this case, an opmask register kO through k7 can be selected. 


¢ In 64-bit mode, 32 vector registers can be encoded using the EVEX prefix. 


° Broadcast may be supported for some instructions on the operand that can be encoded as a memory vector. 
The data elements of a memory vector may be conditionally fetched or written to, and the vector size is 
dependent on the data transformation function. 


¢ Flexible rounding control for the register-to-register flavor of EVEX encoded 512-bit and scalar instructions. 
Four rounding modes are supported by direct encoding within the EVEX prefix, overriding MXCSR settings. 


° Broadcast of one element to the rest of the destination vector register. 


* Compressed 8-bit displacement encoding scheme to increase the instruction encoding density for instructions 
that normally require disp32 syntax. 
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15.6.1 OPMASK Register to Predicate Vector Data Processing 


AVX-512 instructions using EVEX encode a predicate operand to conditionally control per-element computational 
operation and updating of the result to the destination operand. The predicate operand is known as the opmask 
register. The opmask is a set of eight architectural registers of size MAX_KL (64-bit). Note that from this set of eight 
architectural registers, only ki through k7 can be addressed as a predicate operand. kO can be used as a regular 
source or destination but cannot be encoded as a predicate operand. Note also that a predicate operand can be 
used to enable memory fault-suppression for some instructions with a memory operand (source or destination). 


As a predicate operand, the opmask registers contain one bit to govern the operation/update to each data element 
of a vector register. In general, opmask registers can support instructions with all element sizes: byte (int8), word 
(int16), single-precision floating-point (float32), integer doubleword(int32), double-precision floating-point 
(float64), integer quadword (int64). Therefore, a ZMM vector register can hold 8, 16, 32, or 64 elements in prin- 
ciple. The length of an opmask register, MAX_KL, is sufficient to handle up to 64 elements with one bit per element, 
i.e., 64 bits. Masking is supported in most of the AVX-512 instructions. For a given vector length, each instruction 
accesses only the number of least significant mask bits that are needed based on its data type. For example, AVX- 
512 Foundation instructions operating on 64-bit data elements with a 512-bit vector length, only use the 8 least 
significant bits of the opmask register. 


An opmask register affects an AVX-512 instruction at per-element granularity. Any numeric or non-numeric oper- 

ation of each data element and per-element updates of intermediate results to the destination operand are predi- 

cated on the corresponding bit of the opmask register. 

An opmask serving as a predicate operand in AVX-512 obeys the following properties: 

¢ The instruction’s operation is not performed for an element if the corresponding opmask bit is not set. This 
implies that no exception or violation can be caused by an operation on a masked-off element. Consequently, 
no MXCSR exception flag is updated as a result of a masked-off operation. 


¢ Adestination element is not updated with the result of the operation if the corresponding writemask bit is not 
set. Instead, the destination element value must be preserved (merging-masking) or it must be zeroed out 
(zeroing-masking). 


¢ For some instructions with a memory operand, memory faults are suppressed for elements with a mask bit of 
0. 


Note that this feature provides a versatile construct to implement control-flow predication as the mask in effect 

provides a merging behavior for AVX-512 vector register destinations. As an alternative the masking can be used 
for zeroing instead of merging, so that the masked out elements are updated with 0 instead of preserving the old 
value. The zeroing behavior is provided to remove the implicit dependency on the old value when it is not needed. 


Most instructions with masking enabled accept both forms of masking. Instructions that must have EVEX.aaa bits 
different than 0 (gather and scatter) and instructions that write to memory only accept merging-masking. 


It’s important to note that the per-element destination update rule also applies when the destination operand is a 
memory location. Vectors are written on a per element basis, based on the opmask register used as a predicate 
operand. 


The value of an opmask register can be: 

* Generated as a result of a vector instruction (e.g., CMP, FPCLASS, etc.). 
° Loaded from memory. 

¢ Loaded from a GPR register. 

¢ Modified by mask-to-mask operations. 


Opmask registers can be used for purposes outside of predication. For example, they can be used to manipulate 
sparse sets of elements from a vector, or used to set the EFLAGS based on the 0/OxFFFFFFFFFFFFFFFF/other status 
of the OR of two opmask registers. 


15.6.1.1 Opmask Register KO 


The only exception to the opmask rules described above is that opmask kO can not be used as a predicate operand. 
Opmask kO cannot be encoded as a predicate operand for a vector operation; the encoding value that would select 
opmask kO will instead select an implicit op mask value of OxFFFFFFFFFFFFFFFF, thereby effectively disabling 
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masking. Opmask register kO can still be used for any instruction that takes opmask register(s) as operand(s) 


(either source or destination). 


Note that certain instructions implicitly use the opmask as an extra destination operand. In such cases, trying to 


use the “no mask” feature will translate into a #UD fault being raised. 


15.6.1.2 


Example of Opmask Usages 


The example below illustrates the predicated vector add operation and predicated updates of added results into the 
destination operand. The initial state of vector registers zmm0, zmm1i1, and zmm2 and k3 are: 


MSB adage A oie ers Stee aa ae eee eee LSB 
zmmO = 
0x00000003 0x00000002 0x00000001 0x00000000 ] (bytes 15 through 0) 
0x00000007 0x00000006 0x00000005 0x00000004 ] (bytes 31 through 16) 
0x0000000B 0x0000000A 0x00000009 0x00000008 ] (bytes 47 through 32) 
OxO0000000F Ox0000000E 0x0000000D 0x0000000C ] (bytes 63 through 48) 
zmml = 
OxO0000000F Ox0000000F Ox0000000F Ox0000000F ] (bytes 15 through 0) 
[ OxOO00000F Ox0000000F Ox0000000F Ox0000000F ] (bytes 31 through 16) 
OxO0000000F Ox0000000F Ox0000000F Ox0000000F ] (bytes 47 through 32) 
OxO0000000F Ox0000000F Ox0000000F Ox0000000F ] (bytes 63 through 48) 
zmm2 = 
OxAAAAAAAA OxAAAAAAAA OxAAAAAAAA OxXAAAAAAAA ] (bytes 15 through 0) 
OxBBBBBBBB OxXBBBBBBBB OxXBBBBBBBB OxXBBBBBBBB ] (bytes 31 through 16) 
[ OxCCCCCCCC OxCCCCCCCC OxCCCCCCCC OxCCCCCCCC ] (bytes 47 through 32) 
OxDDDDDDDD OxDDDDDDDD OxDDDDDDDD OxDDDDDDDD ] (bytes 63 through 48) 
k3 = 0x8FO03 (1000 1111 0000 0011) 


An opmask register serving as a predicate operand is expressed as a curly-braces-enclosed decorator following the 
first operand in the Intel assembly syntax. Given this state, we will execute the following instruction: 


vpaddd zmm2 {k3}, zmm0, zmm1 


The vpaddd instruction performs 32-bit integer additions on each data element conditionally based on the corre- 
sponding bit value in the predicate operand k3. Since per-element operations are not operated if the corresponding 
bit of the predicate mask is not set, the intermediate result is: 


[ *#*KKK KKK KR ka KKKKEKE OX00000010 Ox0000000F ] (bytes 15 through 0) 

[ ee Rokk Ordo dk bdo kik kkk KR ] (bytes 31 through 16) 
[ 0x0000001A 0x00000019 0x00000018 0x00000017 ] (bytes 47 through 32) 
[ OXOOQ000LE #¥*KKHKKKR KKKKKKKEKK KKEKKEKKEE J] (bytes 63 through 48) 


where "**********" indicates that no operation is performed. 


This intermediate result is then written into the destination vector register, zmm2, using the opmask register k3 as 


the writemask, producing the following final result: 
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zmm2 = 

[ OxXAAAAAAAA OxAAAAAAAA 0x00000010 Ox0000000F ] (bytes 15 through 0) 
[ O0xBBBBBBBB OxXBBBBBBBB OxBBBBBBBB OxXBBBBBBBB ] (bytes 31 through 16) 
[ 0x0000001A 0x00000019 0x00000018 0x00000017 ] (bytes 47 through 32) 
[ 0x0000001E OxDDDDDDDD OxDDDDDDDD OxDDDDDDDD ] (bytes 63 through 48) 


Note that for a 64-bit instruction (for example, vaddpd), only the 8 LSB of mask k3 (0x03) would be used to iden- 
tify the predicate operation on each one of the 8 elements of the source/destination vectors. 


15.6.2 OpMask Instructions 


AVX-512 Foundation instructions provide a collection of opmask instructions that allow programmers to set, copy, 
or operate on the contents of a given opmask register. There are three types of opmask instructions: 


° Mask read/write instructions: These instructions move data between a general-purpose integer register or 
memory and an opmask mask register, or between two opmask registers. For example: 


— kmovw ki, ebx; move lower 16 bits of ebx to k1. 


¢ Flag instructions: This category consists of instructions that modify EFLAGS based on the content of opmask 
registers. 


— kortestw ki, k2; OR registers k1 and k2 and updated EFLAGS accordingly. 


¢ Mask logical instructions: These instructions perform standard bitwise logical operations between opmask 
registers. 


— kandw ki, k2, k3; AND lowest 16 bits of registers k2 and k3, leaving the result in k1. 


15.6.3. Broadcast 


EVEX encoding provides a bit-field to encode data broadcast for some load-op instructions, i.e., instructions that 
load data from memory and perform some computational or data movement operation. A source element from 
memory can be broadcasted (repeated) across all the elements of the effective source operand (up to 16 times for 
a 32-bit data element, up to 8 times for a 64-bit data element). This is useful when we want to reuse the same 
scalar operand for all the operations in a vector instruction. Broadcast is only enabled on instructions with an 
element size of 32 bits or 64 bits. Byte and word instructions do not support embedded broadcast. 

The functionality of data broadcast is expressed as a curly-braces-enclosed decorator following the last 
register/memory operand in the Intel assembly syntax. 


For instance: 


vmulps zmml, zmm2, [rax] {1to16} 


The {1to16} primitive loads one float32 (single precision) element from memory, replicates it 16 times to form a 
vector of 16 32-bit floating-point elements, multiplies the 16 float32 elements with the corresponding elements in 
the first source operand vector, and puts each of the 16 results into the destination operand. 


AVX-512 instructions with store semantics and pure load instructions do not support broadcast primitives. 


vmovaps [rax] {k3}, zmm19 


In contrast, the k3 opmask register is used as the predicate operand in the above example. Only the store opera- 
tion on data elements corresponding to the non-zero bits in k3 will be performed. 
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15.6.4 Static Rounding Mode and Suppress All Exceptions 


In previous SIMD instruction extensions (up to AVX and AVX2), rounding control is generally specified in MXCSR, 
with a handful of instructions providing per-instruction rounding override via encoding fields within the imm8 
operand. AVX-512 offers a more flexible encoding attribute to override MXCSR-based rounding control for floating- 
pointing instructions with rounding semantics. This rounding attribute embedded in the EVEX prefix is called Static 
(per instruction) Rounding Mode or Rounding Mode override. This attribute allows programmers to statically apply 
a specific arithmetic rounding mode irrespective of the value of RM bits in MXCSR. It is available only to register-to- 
register flavors of EVEX-encoded floating-point instructions with rounding semantic. The differences between these 
three rounding control interfaces are summarized in Table 15-4. 


Table 15-4. Characteristics of Three Rounding Control Interfaces 


Rounding Interface Stans Rounding ime embeds Rounding MXCSR Rounding Control 
Override Override 
Semantic Requirement FP rounding FP rounding FP rounding 
Prefix Requirement EVEX.B = 1 NA NA 
Rounding Control EVEX.LL IMM8[1:0] or MXCSR.RC MXCSR.RC 
(depending on IMM8[2]) 
Suppress All Exceptions (SAE) Implied no no 
SIMD FP Exception #XM All suppressed Can raise #l, #P (unless SPE is set) | MXCSR masking controls 
MXCSR flag update No yes (except PE if SPE is set) Yes 
Precedence Above MXCSR.RC Above EVEX.UL Default 
Scope 512-bit, reg-reg, ROUNDPx, ROUNDSx, All SIMD operands, vector lengths 
Scalar reg-reg VCVTPS2PH, VRNDSCALExx 


The static rounding-mode override in AVX-512 also implies the “suppress-all-exceptions” (SAE) attribute. The SAE 
effect is as if all the MXCSR mask bits are set, and none of the MXCSR flags will be updated. Using static rounding- 
mode via EVEX without SAE is not supported. 


Static Rounding Mode and SAE control can be enabled in the encoding of the instruction by setting the EVEX.b bit 
to 1 in a register-register vector instruction. In such a case, vector length is assumed to be MAXVL (512-bit in case 
of AVX-512 packed vector instructions) or 128-bit for scalar instructions. Table 15-5 summarizes the possible static 
rounding-mode assignments in AVX-512 instructions. 


Note that some instructions already allow specifying the rounding mode statically via immediate bits. In such 
cases, the immediate bits take precedence over the embedded rounding mode (in the same vein that they take 
precedence over whatever MXCSR.RM says). 


Table 15-5. Static Rounding Mode 


Function Description 

{rn-sae} Round to nearest (even) + SAE 
{rd-sae} Round down (toward -inf) + SAE 
{ru-Sae} Round up (toward +inf) + SAE 
{rz-sae} Round toward zero (Truncate) + SAE 


An example of use would be as follows: 


vaddps zmm7 {k6}, zmm2, zmm4, {rd-sae} 


This would perform the single-precision floating-point addition of vectors zmm2 and zmm4 with round-towards- 
minus-infinity, leaving the result in vector zmm7 using k6 as conditional writemask. 


15-12 Vol.1 


PROGRAMMING WITH INTEL® AVX-512 


Note that MXCSR.RM bits are ignored and unaffected by the outcome of this instruction. 
Examples of instruction instances where the static rounding-mode is not allowed are shown below: 


; rounding-mode already specified in the instruction immediate 


vrndscaleps zmm7 {k6}, zmm2, 0x00 


; instructions with memory operands 


vmulps zmm7 {k6}, zmm2, [rax], {rd-sae} 


; instructions with vector length different than MAXVL (512-bit) 


vaddps ymm7 {k6}, ymm2, ymm4, {rd-sae} 


15.6.5 Compressed Disp8*N Encoding 


EVEX encoding supports a new displacement representation that allows for a more compact encoding of memory 
addressing commonly used in unrolled code, where an 8-bit displacement can address a range exceeding the 
dynamic range of an 8-bit value. This compressed displacement encoding is referred to as disp8*N, where N is a 
constant implied by the memory operation characteristic of each instruction. 


The compressed displacement is based on the assumption that the effective displacement (of a memory operand 
occurring in a loop) is a multiple of the granularity of the memory access of each iteration. Since the base register 
in memory addressing already provides byte-granular resolution, the lower bits of the traditional disp8 operand 
become redundant, and can be implied from the memory operation characteristic. 


The memory operation characteristics depend on the following: 
° The destination operand is updated as a full vector, a single element, or multi-element tuples. 


¢ The memory source operand (or vector source operand if the destination operand is memory) is fetched (or 
treated) as a full vector, a single element, or multi-element tuples. 


For example: 
vaddps zmm7, zmm2, disp8[membase + index*8] 


The destination zmm7 is updated as a full 512-bit vector, and 64-bytes of data are fetched from memory as a full 
vector; the next unrolled iteration may fetch from memory in 64-byte granularity per iteration. There are 6 bits of 
lowest address that can be compressed, hence N = 2%6 = 64. The contribution of “disp8” to effective address 
calculation is 64*disp8. 


vbroadcastf£32x4 zmm7, disp8[membase + index*8] 


In VBROADCASTF32x4, memory is fetched as a 4tuple of 4 32-bit entities. Hence the common lowest address bits 
that can be compressed are 4, corresponding to the 4tuple width of 2“%4 = 16 bytes (4x32 bits). Therefore, N = 
244. 

For EVEX encoded instructions that update only one element in the destination, or the source element is fetched 
individually, the number of lowest address bits that can be compressed is generally the width in bytes of the data 
element, hence N = 2“(width). 


15.7. MEMORY ALIGNMENT 


Memory alignment requirements on EVEX-encoded SIMD instructions are similar to VEX-encoded SIMD instruc- 
tions. Memory alignment applies to EVEX-encoded SIMD instructions in three categories: 


¢ —Explicitly-aligned SIMD load and store instructions accessing 64 bytes of memory with EVEX prefix encoded 
vector length of 512 bits (e.g., VMOVAPD, VMOVAPS, VMOVDQA, etc.). These instructions always require the 
memory address to be aligned on a 64-byte boundary. 


Vol.1 15-13 


PROGRAMMING WITH INTEL® AVX-512 


¢ = Explicitly-unaligned SIMD load and store instructions accessing 64 bytes or less of data from memory (eé.g., 
VMOVUPD, VMOVUPS, VMOVDQU, VMOVQ, VMOVD, etc.). These instructions do not require the memory 
address to be aligned on a natural vector-length byte boundary. 


* Most arithmetic and data processing instructions encoded using EVEX support memory access semantics. 
When these instructions access from memory, there are no alignment restrictions. 


Software may see performance penalties when unaligned accesses cross cacheline boundaries or vector-length 
naturally-aligned boundaries, so reasonable attempts to align commonly used data sets should continue to be 
pursued. 


Atomic memory operation in Intel 64 and IA-32 architecture is guaranteed only for a subset of memory operand 
sizes and alignment scenarios. The guaranteed atomic operations are described in Section 8.1.1, “Guaranteed 
Atomic Operations” of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. AVX and 
FMA instructions do not introduce any new guaranteed atomic memory operations. 


AVX-512 instructions may generate an #AC(0) fault on misaligned 4 or 8-byte memory references in Ring-3 when 
CRO.AM=1. 16, 32 and 64-byte memory references will not generate an #AC(0) fault. See Table 15-7 for details. 


Certain AVX-512 Foundation instructions always require 64-byte alignment (see the complete list of VEX and EVEX 
encoded instructions in Table 15-6). These instructions will #GP(0) if not aligned to 64-byte boundaries. 


Table 15-6. SIMD Instructions Requiring Explicitly Aligned Memory 


Require 16-byte alignment Require 32-byte alignment Require 64-byte alignment* 


(V)MOVDQA xmm, m128 


VMOVDOA ymm, m256 


VMOVDOA zmm, m512 


(V)MOVDQA m1 28, xmm 


VMOVDOA m256, ymm 


VMOVDOA m512, zmm 


(V)JMOVAPS xmm, m128 
( 


VMOVAPS ymm, m256 
VMOVAPS m256, ymm 


VMOVAPS zmm, m512 
VMOVAPS m512, zmm 


) 
V)MOVAPS m128, xmm 
V)MOVAPD xmm, m128 


VMOVAPD ymm, m256 


VMOVAPD zmm, m512 


( 
(V)MOVAPD m128, xmm 
(V)MOVNTDOA xmm, m128 


VMOVAPD m256, ymm 
VMOVNTPS m256, ymm 


VMOVAPD m512, zmm 
VMOVNTPS m512, zmm 


(V)MOVNTPS m128, xmm 


VMOVNTPD m256, ymm 


VMOVNTPD m512, zmm 


(V)MOVNTPD m128, xmm 
(V)MOVNTDQ m128, xmm 


VMOVNTDQ m256, ymm 
VMOVNTDOA ymm, m256 


VMOVNTDQ m512, zmm 
VMOVNTDQA zmm, m512 


Table 15-7. Instructions Not Requiring Explicit Memory Alignment 


(V)MOVDQU xmm, m128 


VMOVDQU ymm, m256 


VMOVDQU zmm, m512 


(V)MOVDQU m128, m128 


VMOVDQU m256, ymm 


VMOVDQU m512, zmm 


(V)JMOVUPS xmm, m128 


VMOVUPS ymm, m256 


VMOVUPS zmm, m512 


(V)JMOVUPS m128, xmm 


VMOVUPS m256, ymm 


VMOVUPS m512, zmm 


V)MOVUPD xmm, m128 


( 
(VJMOVUPD m128, xmm 


VMOVUPD ymm, m256 
VMOVUPD m256, ymm 


VMOVUPD zmm, m512 
VMOVUPD m512, zmm 


15.8 SIMD FLOATING-POINT EXCEPTIONS 


AVX-512 instructions can generate SIMD floating-point exceptions (#XM) if embedded “suppress all exceptions” 
(SAE) in EVEX is not set. When SAE is not set, these instructions will respond to exception masks of MXCSR in the 
same way as VEX-encoded AVX instructions. When CR4.0SXMMEXCPT=0, any unmasked FP exceptions generate 
an Undefined Opcode exception (#UD). 
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15.9 INSTRUCTION EXCEPTION SPECIFICATION 


Exception behavior of VEX-encoded AVX / AVX2 instructions are described in Inte/® 64 and IA-32 Architectures 
Software Developer’s Manual, Volume 2A. Exception behavior of AVX-512 Foundation instructions and additional 
512-bit extensions are described in Section 2.7, “Exception Classifications of EVEX-Encoded instructions” and 
Section 2.8, “Exception Classifications of Opmask instructions”. 


15.10 EMULATION 


Setting the CRO.EM bit to 1 provides a technique to emulate legacy SSE floating-point instruction sets in software. 
This technique is not supported with AVX instructions, nor FMA instructions. 


If an operating system wishes to emulate AVX instructions, set XCRO[2:1] to zero. This will cause AVX instructions 
to #UD. Emulation of FMA by the operating system can be done similarly as with emulating AVX instructions. 


15.11. WRITING FLOATING-POINT EXCEPTION HANDLERS 


AVX-512, AVX and FMA floating-point exceptions are handled in an entirely analogous way to legacy SSE floating- 
point exceptions. To handle unmasked SIMD floating-point exceptions, the operating system or executive must 
provide an exception handler. Section 11.5.1, “SIMD Floating-Point Exceptions”, describes the SIMD floating-point 
exception classes and gives suggestions for writing an exception handler to handle them. 


To indicate that the operating system provides a handler for SIMD floating-point exceptions (#XM), the CR4.0SXM- 
MEXCPT flag (bit 10) must be set. 
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CHAPTER 16 
PROGRAMMING WITH INTEL® TRANSACTIONAL SYNCHRONIZATION 
EXTENSIONS 


16.1 OVERVIEW 


This chapter describes the software programming interface to the Intel® Transactional Synchronization Extensions 
of the Intel 64 architecture. 


Multithreaded applications take advantage of increasing number of cores to achieve high performance. However, 
writing multi-threaded applications requires programmers to reason about data sharing among multiple threads. 
Access to shared data typically requires synchronization mechanisms. These mechanisms ensure multiple threads 
update shared data by serializing operations on the shared data, often through the use of a critical section 
protected by a lock. Since serialization limits concurrency, programmers try to limit synchronization overheads. 
They do this either through minimizing the use of synchronization or through the use of fine-grain locks; where 
multiple locks each protect different shared data. Unfortunately, this process is difficult and error prone; a missed 
or incorrect synchronization can cause an application to fail. Conservatively adding synchronization and using 
coarser granularity locks, where a few locks each protect many items of shared data, helps avoid correctness prob- 
lems but limits performance due to excessive serialization. While programmers must use static information to 
determine when to Serialize, the determination as to whether actually to serialize is best done dynamically. 


Intel® Transactional Synchronization Extensions aim to improve the performance of lock-protected critical sections 
while maintaining the lock-based programming model. 


16.2 INTEL® TRANSACTIONAL SYNCHRONIZATION EXTENSIONS 


Intel® Transactional Synchronization Extensions (Intel® TSX) allow the processor to determine dynamically 
whether threads need to serialize through lock-protected critical sections, and to perform serialization only when 
required. This lets the hardware expose and exploit concurrency hidden in an application due to dynamically unnec- 
essary synchronization through a technique known as lock elision. 


With lock elision, the hardware executes the programmer-specified critical sections (also referred to as transac- 
tional regions) transactionally. In such an execution, the lock variable is only read within the transactional region; 
it is not written to (and therefore not acquired) with the expectation that the lock variable remains unchanged after 
the transactional region, thus exposing concurrency. 


If the transactional execution completes successfully, then the hardware ensures that all memory operations 
performed within the transactional region will appear to have occurred instantaneously when viewed from other 
logical processors, a process referred to as an atomic commit. Any updates performed within the transactional 
region are made visible to other processors only on an atomic commit. 


Since a successful transactional execution ensures an atomic commit, the processor can execute the programmer- 
specified code section optimistically without synchronization. If synchronization was unnecessary for that specific 
execution, execution can commit without any cross-thread serialization. 


If the transactional execution is unsuccessful, the processor cannot commit the updates atomically. When this 
happens, the processor will roll back the execution, a process referred to as a transactional abort. On a transac- 
tional abort, the processor will discard all updates performed in the region, restore architectural state to appear as 
if the optimistic execution never occurred, and resume execution non-transactionally. Depending on the policy in 
place, lock elision may be retried or the lock may be explicitly acquired to ensure forward progress. 


Intel TSX provides two software interfaces for programmers. 


¢ Hardware Lock Elision (HLE) is a legacy compatible instruction set extension (comprising the XACQUIRE and 
XRELEASE prefixes). 


¢ Restricted Transactional Memory (RTM) is a new instruction set interface (comprising the XBEGIN and XEND 
instructions). 
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Programmers who would like to run Intel TSX-enabled software on legacy hardware would use the HLE interface to 
implement lock elision. On the other hand, programmers who do not have legacy hardware requirements and who 
deal with more complex locking primitives would use the RTM software interface of Intel TSX to implement lock 
elision. In the latter case when using new instructions, the programmer must always provide a non-transactional 
path (which would have code to eventually acquire the lock being elided) to execute following a transactional abort 
and must not rely on the transactional execution alone. 


In addition, Intel TSX also provides the XTEST instruction to test whether a logical processor is executing transac- 
tionally, and the XABORT instruction to abort a transactional region. 


A processor can perform a transactional abort for numerous reasons. A primary cause is due to conflicting accesses 
between the transactionally executing logical processor and another logical processor. Such conflicting accesses 
may prevent a successful transactional execution. Memory addresses read from within a transactional region 
constitute the read-set of the transactional region and addresses written to within the transactional region consti- 
tute the write-set of the transactional region. Intel TSX maintains the read- and write-sets at the granularity of a 
cache line. 


A conflicting data access occurs if another logical processor either reads a location that is part of the transactional 
region’s write-set or writes a location that is a part of either the read- or write-set of the transactional region. We 
refer to this as a data conflict. Since Intel TSX detects data conflicts at the granularity of a cache line, unrelated 
data locations placed in the same cache line will be detected as conflicts. Transactional aborts may also occur due 
to limited transactional resources. For example, the amount of data accessed in the region may exceed an imple- 
mentation-specific capacity. Additionally, some instructions and system events may cause transactional aborts. 


16.2.1 HLE Software Interface 
HLE provides two new instruction prefix hints: XACQUIRE and XRELEASE. 


The programmer uses the XACQUIRE prefix in front of the instruction that is used to acquire the lock that is 
protecting the critical section. The processor treats the indication as a hint to elide the write associated with the 
lock acquire operation. Even though the lock acquire has an associated write operation to the lock, the processor 
does not add the address of the lock to the transactional region’s write-set nor does it issue any write requests to 
the lock. Instead, the address of the lock is added to the read-set. The logical processor enters transactional execu- 
tion. If the lock was available before the XACQUIRE prefixed instruction, all other processors will continue to see it 
as available afterwards. Since the transactionally executing logical processor neither added the address of the lock 
to its write-set nor performed externally visible write operations to it, other logical processors can read the lock 
without causing a data conflict. This allows other logical processors to also enter and concurrently execute the crit- 
ical section protected by the lock. The processor automatically detects any data conflicts that occur during the 
transactional execution and will perform a transactional abort if necessary. 


Even though the eliding processor did not perform any external write operations to the lock, the hardware ensures 
program order of operations on the lock. If the eliding processor itself reads the value of the lock in the critical 
section, it will appear as if the processor had acquired the lock, i.e. the read will return the non-elided value. This 
behavior makes an HLE execution functionally equivalent to an execution without the HLE prefixes. 


The programmer uses the XRELEASE prefix in front of the instruction that is used to release the lock protecting the 
critical section. This involves a write to the lock. If the instruction is restoring the value of the lock to the value it 
had prior to the XACQUIRE prefixed lock acquire operation on the same lock, then the processor elides the external 
write request associated with the release of the lock and does not add the address of the lock to the write-set. The 
processor then attempts to commit the transactional execution. 


With HLE, if multiple threads execute critical sections protected by the same lock but they do not perform any 
conflicting operations on each other’s data, then the threads can execute concurrently and without serialization. 
Even though the software uses lock acquisition operations on a common lock, the hardware recognizes this, elides 
the lock, and executes the critical sections on the two threads without requiring any communication through the 
lock — if such communication was dynamically unnecessary. 


If the processor is unable to execute the region transactionally, it will execute the region non-transactionally and 
without elision. HLE enabled software has the same forward progress guarantees as the underlying non-HLE lock- 
based execution. For successful HLE execution, the lock and the critical section code must follow certain guidelines 
(discussed in Section 16.3.3 and Section 16.3.8). These guidelines only affect performance; not following these 
guidelines will not cause a functional failure. 
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Hardware without HLE support will ignore the XACQUIRE and XRELEASE prefix hints and will not perform any 
elision since these prefixes correspond to the REPNE/REPE IA-32 prefixes which are ignored on the instructions 
where XACQUIRE and XRELEASE are valid. Importantly, HLE is compatible with the existing lock-based program- 
ming model. Improper use of hints will not cause functional bugs though it may expose latent bugs already in the 
code. 


16.2.2 RTM Software Interface 
RTM provides three new instructions: XBEGIN, XEND, and XABORT. 


Software uses the XBEGIN instruction to specify the start of the transactional region and the XEND instruction to 
specify the end of the transactional region. The XBEGIN instruction takes an operand that provides a relative offset 
to the fallback instruction address if the transactional region could not be successfully executed transactionally. 
Software using these instructions to implement lock elision must test the lock within the transactional region, and 
only if free should try to commit. Further, the software may also define a policy to retry if the lock is not free. 


A processor may abort transactional execution for many reasons. The hardware automatically detects transactional 
abort conditions and restarts execution from the fallback instruction address with the architectural state corre- 
sponding to that at the start of the XBEGIN instruction and the EAX register updated to describe the abort status. 


The XABORT instruction allows programmers to abort the execution of a transactional region explicitly. The 
XABORT instruction takes an 8 bit immediate argument that is loaded into the EAX register and will thus be avail- 
able to software following a transactional abort. 


Hardware provides no guarantees as to whether a transactional execution will ever successfully commit. Program- 
mers must always provide an alternative code sequence in the fallback path to guarantee forward progress. When 
using the instructions for lock elision, this may be as simple as acquiring a lock and executing the specified code 
region non-transactionally. Further, a transactional region that always aborts on a given implementation may 
complete transactionally on a future implementation. Therefore, programmers must ensure the code paths for the 
transactional region and the alternative code sequence are functionally tested. 


If the RTM software interface is used for anything other than lock elision, the programmer must similarly ensure 
that the fallback path is inter-operable with the transactionally executing path. 


16.3. INTEL® TSX APPLICATION PROGRAMMING MODEL 


16.3.1 Detection of Transactional Synchronization Support 


16.3.1.1 Detection of HLE Support 


A processor supports HLE execution if CPUID.0O7H.EBX.HLE [bit 4] = 1. However, an application can use the HLE 
prefixes (XACQUIRE and XRELEASE) without checking whether the processor supports HLE. Processors without 
HLE support ignore these prefixes and will execute the code without entering transactional execution. 


16.3.1.2 Detection of RTM Support 


A processor supports RTM execution if CPUID.O7H.EBX.RTM [bit 11] = 1. An application must check if the processor 
supports RTM before it uses the RTM instructions (XBEGIN, XEND, XABORT). These instructions will generate a 
#UD exception when used on a processor that does not support RTM. 


16.3.1.3 Detection of XTEST Instruction 


A processor supports the XTEST instruction if it supports either HLE or RTM. An application must check either of 
these feature flags before using the XTEST instruction. This instruction will generate a #UD exception when used 
on a processor that does not support either HLE or RTM. 
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16.3.2 Querying Transactional Execution Status 


The XTEST instruction can be used to determine the transactional status of a transactional region specified by HLE 
or RTM. Note, while the HLE prefixes are ignored on processors that do not support HLE, the XTEST instruction will 
generate a #UD exception when used on processors that do not support either HLE or RTM. 


16.3.3 Requirements for HLE Locks 


For HLE execution to successfully commit transactionally, the lock must satisfy certain properties and access to the 
lock must follow certain guidelines. 


¢ An XRELEASE prefixed instruction must restore the value of the elided lock to the value it had before the lock 
acquisition. This allows hardware to safely elide locks by not adding them to the write-set. The data size and 
data address of the lock release (XRELEASE prefixed) instruction must match that of the lock acquire 
(XACQUIRE prefixed) and the lock must not cross a cache line boundary. 


¢ Software should not write to the elided lock inside a transactional HLE region with any instruction other than an 
XRELEASE prefixed instruction, otherwise it may cause a transactional abort. In addition, recursive locks 
(where a thread acquires the same lock multiple times without first releasing the lock) may also cause a trans- 
actional abort. Note that software can observe the result of the elided lock acquire inside the critical section. 
Such a read operation will return the value of the write to the lock. 


The processor automatically detects violations to these guidelines, and safely transitions to a non-transactional 
execution without elision. Since Intel TSX detects conflicts at the granularity of a cache line, writes to data collo- 
cated on the same cache line as the elided lock may be detected as data conflicts by other logical processors eliding 
the same lock. 


16.3.4 Transactional Nesting 


Both HLE- and RTM-based transactional executions support nested transactional regions. However, a transactional 
abort restores state to the operation that started transactional execution: either the outermost XACQUIRE prefixed 
HLE eligible instruction or the outermost XBEGIN instruction. The processor treats all nested transactional regions 
as one monolithic transactional region. 


16.3.4.1 HLE Nesting and Elision 


Programmers can nest HLE regions up to an implementation specific depth of MAX_HLE_NEST_COUNT. Each logical 
processor tracks the nesting count internally but this count is not available to software. An XACQUIRE prefixed HLE- 
eligible instruction increments the nesting count, and an XRELEASE prefixed HLE-eligible instruction decrements it. 
The logical processor enters transactional execution when the nesting count goes from zero to one. The logical 
processor attempts to commit only when the nesting count becomes zero. A transactional abort may occur if the 
nesting count exceeds MAX_HLE_NEST_COUNT. 


In addition to supporting nested HLE regions, the processor can also elide multiple nested locks. The processor 
tracks a lock for elision beginning with the XACQUIRE prefixed HLE eligible instruction for that lock and ending with 
the XRELEASE prefixed HLE eligible instruction for that same lock. The processor can, at any one time, track up to 
a MAX_HLE_ELIDED_LOCKS number of locks. For example, if the implementation supports a 
MAX_HLE_ELIDED_LOCKS value of two and if the programmer nests three HLE identified critical sections (by 
performing XACQUIRE prefixed HLE eligible instructions on three distinct locks without performing an intervening 
XRELEASE prefixed HLE eligible instruction on any one of the locks), then the first two locks will be elided, but the 
third won't be elided (but will be added to the transaction’s write-set). However, the execution will still continue 
transactionally. Once an XRELEASE for one of the two elided locks is encountered, a subsequent lock acquired 
through the XACQUIRE prefixed HLE eligible instruction will be elided. 


The processor attempts to commit the HLE execution when all elided XACQUIRE and XRELEASE pairs have been 
matched, the nesting count goes to zero, and the locks have satisfied the requirements described earlier. If execu- 
tion cannot commit atomically, then execution transitions to a non-transactional execution without elision as if the 
first instruction did not have an XACQUIRE prefix. 
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16.3.4.2 RTM Nesting 


Programmers can nest RTM-based transactional regions up to an implementation specific 
MAX_RTM_NEST_COUNT. The logical processor tracks the nesting count internally but this count is not available to 
software. An XBEGIN instruction increments the nesting count, and an XEND instruction decrements it. The logical 
processor attempts to commit only if the nesting count becomes zero. A transactional abort occurs if the nesting 
count exceeds MAX_RTM_NEST_COUNT. 


16.3.4.3. Nesting HLE and RTM 


HLE and RTM provide two alternative software interfaces to a common transactional execution capability. The 
behavior when HLE and RTM are nested together—HLE inside RTM or RTM inside HLE—is implementation specific. 
However, in all cases, the implementation will maintain HLE and RTM semantics. An implementation may choose to 
ignore HLE hints when used inside RTM regions, and may cause a transactional abort when RTM instructions are 
used inside HLE regions. In the latter case, the transition from transactional to non-transactional execution occurs 
seamlessly since the processor will re-execute the HLE region without actually doing elision, and then execute the 
RTM instructions. 


16.3.5 RTM Abort Status Definition 


RTM uses the EAX register to communicate abort status to software. Following an RTM abort the EAX register has 
the following definition. 


Table 16-1. RTM Abort Status Definition 


EAX Register Bit Meaning 
Position 
0 Set if abort caused by XABORT instruction. 
1 If set, the transactional execution may succeed on a retry. This bit is always clear if bit O is set. 
2 Set if another logical processor conflicted with a memory address that was part of the transactional execution 
that aborted. 

3 Set if an internal buffer to track transactional state overflowed. 
4 Set if a debug exception (#DB) or breakpoint exception (#BP) was hit. 
5 Set if an abort occurred during execution of a nested transactional execution. 

23:6 Reserved. 

31:24 XABORT argument (only valid if bit O set, otherwise reserved). 


The EAX abort status for RTM only provides causes for aborts. It does not by itself encode whether an abort or 
commit occurred for the RTM region. The value of EAX can be 0 following an RTM abort. For example, a CPUID 
instruction when used inside an RTM region causes a transactional abort and may not satisfy the requirements for 
setting any of the EAX bits. This may result in an EAX value of 0. 


16.3.6 RTM Memory Ordering 


A successful RTM commit causes all memory operations in the RTM region to appear to execute atomically. A 
successfully committed RTM region consisting of an XBEGIN followed by an XEND, even with no memory operations 
in the RTM region, has the same ordering semantics as a LOCK prefixed instruction. 


The XBEGIN instruction does not have fencing semantics. However, if an RTM execution aborts, all memory 
updates from within the RTM region are discarded and never made visible to any other logical processor. 
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16.3.7. RTM-Enabled Debugger Support 


Any debug exception (#DB) or breakpoint exception (#BP) inside an RTM region causes a transactional abort and, 
by default, redirects control flow to the fallback instruction address with architectural state recovered and bit 4 in 
EAX set. However, to allow software debuggers to intercept execution on debug or breakpoint exceptions, the RTM 
architecture provides additional capability called advanced debugging of RTM transactional regions. 


Advanced debugging of RTM transactional regions is enabled if bit 11 of DR7 and bit 15 of the IA32_DEBUGCTL MSR 
are both 1. In this case, any RTM transactional abort due to a #DB or #BP causes execution to roll back to just 
before the XBEGIN instruction (EAX is restored to the value it had before XBEGIN) and then delivers a #DB. (A #DB 
is delivered even if the transactional abort was caused by a #BP.) DR6[16] is cleared to indicate that the exception 
resulted from a debug or breakpoint exception inside an RTM region. See also Section 17.3.3, “Debug Exceptions, 
Breakpoint Exceptions, and Restricted Transactional Memory (RTM),” of Inte/® 64 and IA-32 Architectures Soft- 
ware Developer’s Manual, Volume 3B. 


16.3.8 | Programming Considerations 


Typical programmer-identified regions are expected to execute transactionally and to commit successfully. 
However, Intel TSX does not provide any such guarantee. A transactional execution may abort for many reasons. 
To take full advantage of the transactional capabilities, programmers should follow certain guidelines to increase 
the probability of their transactional execution committing successfully. 


This section discusses various events that may cause transactional aborts. The architecture ensures that updates 
performed within a transactional region that subsequently aborts execution will never become visible. Only a 
committed transactional execution updates architectural state. Transactional aborts never cause functional failures 
and only affect performance. 


16.3.8.1 Instruction Based Considerations 


Programmers can use any instruction safely inside a transactional region. Further, programmers can use the Intel 
TSX instructions and prefixes at any privilege level. However, some instructions will always abort the transactional 
execution and cause execution to seamlessly and safely transition to a non-transactional path. 


Intel TSX allows for most common instructions to be used inside transactional regions without causing aborts. The 
following operations inside a transactional region do not typically cause an abort. 


® Operations on the instruction pointer register, general purpose registers (GPRs) and the status flags (CF, OF, SF, 
PF, AF, and ZF). 

* Operations on XMM and YMM registers and the MXCSR register 

However, programmers must be careful when intermixing SSE and AVX operations inside a transactional region. 


Intermixing SSE instructions accessing XMM registers and AVX instructions accessing YMM registers may cause 
transactional regions to abort. 


CLD and STD instructions when used inside transactional regions may cause aborts if they change the value of the 
DF flag. However, if DF is 1, the STD instruction will not cause an abort. Similarly, if DF is 0, the CLD instruction will 
not cause an abort. 


Instructions not enumerated here as causing abort when used inside a transactional region will typically not cause 
the execution to abort (examples include but are not limited to MFENCE, LFENCE, SFENCE, RDTSC, RDTSCP, etc.). 


The following instructions will abort transactional execution on any implementation: 


° XABORT 
° CPUID 
° PAUSE 
° ENCLS 
° ENCLU 


In addition, in some implementations, the following instructions may always cause transactional aborts. These 
instructions are not expected to be commonly used inside typical transactional regions. However, programmers 
must not rely on these instructions to force a transactional abort, since whether they cause transactional aborts is 
implementation dependent. 
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¢ Operations on X87 and MMX architecture state. This includes all MMX and X87 instructions, including the 
FXRSTOR and FXSAVE instructions. 


° Update to non-status portion of EFLAGS: CLI, STI, POPFD, POPFQ, CLAC and STAC. 


¢ Instructions that update segment registers, debug registers and/or control registers: MOV to 
DS/ES/FS/GS/SS, POP DS/ES/FS/GS/SS, LDS, LES, LFS, LGS, LSS, SWAPGS, WRFSBASE, WRGSBASE, LGDT, 
SGDT, LIDT, SIDT, LLDT, SLDT, LTR, STR, Far CALL, Far JMP, Far RET, IRET, MOV to DRx, MOV to 
CRO/CR2/CR3/CR4/CR8, CLTS, and LMSW. 


° Ring transitions: SYSENTER, SYSCALL, SYSEXIT, and SYSRET. 


¢ TLB and Cacheability control: CLFLUSH, CLFLUSHOPT, CLWB, INVD, WBINVD, INVLPG, INVPCID, and memory 
instructions with a non-temporal hint (V/MOVNTDQA, V/MOVNTDQ, V/MOVNTI, V/MOVNTPD, V/MOVNTPS, 
V/MOVNTQ, V/MASKMOVQ, and V/MASKMOVDQU). 


¢ Extended state management: XRSTOR, XRSTORS, XSAVE, XSAVEC, XSAVEOPT, XSAVES, and XSETBV. 
¢ Interrupts: INT n, INTO, INT3, INT1. 
° I/O: IN, INS, REP INS, OUT, OUTS, REP OUTS and their variants. 


° VMX: VMPTRLD, VMPTRST, VMCLEAR, VMREAD, VMWRITE, VMCALL, VMLAUNCH, VMRESUME, VMXOFF, 
VMXON, INVEPT, INVVPID, and VMFUNC. 


* SMX: GETSEC. 
* UDO, UD1, UD2, RSM, RDMSR, WRMSR, WRPKRU, HLT, MONITOR, MWAIT, and VZEROUPPER. 


16.3.8.2 Runtime Considerations 


In addition to the instruction-based considerations, runtime events may cause transactional execution to abort. 
These may be due to data access patterns or micro-architectural implementation causes. Keep in mind that the 
following list is not a comprehensive discussion of all abort causes. 


Any fault or trap in a transactional region that must be exposed to software will be suppressed. Transactional 
execution will abort and execution will transition to a non-transactional execution, as if the fault or trap had never 
occurred. If any exception is not masked, that will result in a transactional abort and it will be as if the exception 
had never occurred. 


When executed in VMX non-root operation, certain instructions may result in a VM exit. When such instructions are 
executed inside a transactional region, then instead of causing a VM exit, they will cause a transactional abort and 
the execution will appear as if instruction that would have caused a VM exit never executed. 


Synchronous exception events (#DE, #OF, #NP, #SS, #GP, #BR, #UD, #AC, #XM, #PF, #NM, #TS, #MF, #DB, 
#BP/INT3) that occur during transactional execution may cause an execution not to commit transactionally, and 
require a non-transactional execution. These events are suppressed as if they had never occurred. With HLE, since 
the non-transactional code path is identical to the transactional code path, these events will typically re-appear 
when the instruction that caused the exception is re-executed non-transactionally, causing the associated synchro- 
nous events to be delivered appropriately in the non-transactional execution. The same behavior also applies to 
synchronous events (EPT violations, EPT misconfigurations, and accesses to the APIC-access page) that occur in 
VMX non-root operation. 


Asynchronous events (NMI, SMI, INTR, IPI, PMI, etc.) occurring during transactional execution may cause the 
transactional execution to abort and transition to a non-transactional execution. The asynchronous events will be 
pended and handled after the transactional abort is processed. The same behavior also applies to asynchronous 
events (VMX-preemption timer expiry, virtual-interrupt delivery, and interrupt-window exiting) that occur in VMX 
non-root operation. 


Transactional execution only supports write-back cacheable memory type operations. A transactional region may 
always abort if it includes operations on any other memory type. This includes instruction fetches to UC memory 
type. 

Memory accesses within a transactional region may require the processor to set the Accessed and Dirty flags of the 
referenced page table entry. The behavior of how the processor handles this is implementation specific. Some 
implementations may allow the updates to these flags to become externally visible even if the transactional region 
subsequently aborts. Some Intel TSX implementations may choose to abort the transactional execution if these 
flags need to be updated. Further, a processor's page-table walk may generate accesses to its own transactionally 
written but uncommitted state. Some Intel TSX implementations may choose to abort the execution of a transac- 
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tional region in such situations. Regardless, the architecture ensures that, if the transactional region aborts, then 
the transactionally written state will not be made architecturally visible through the behavior of structures such as 
TLBs. 


Executing self-modifying code transactionally may also cause transactional aborts. Programmers must continue to 
follow the Intel recommended guidelines for writing self-modifying and cross-modifying code even when employing 
Intel TSX. 


While an Intel TSX implementation will typically provide sufficient resources for executing common transactional 
regions, implementation constraints and excessive sizes for transactional regions may cause a transactional execu- 
tion to abort and transition to a non-transactional execution. The architecture provides no guarantee of the amount 
of resources available to do transactional execution and does not guarantee that a transactional execution will ever 
succeed. 


Conflicting requests to a cache line accessed within a transactional region may prevent the transactional region 
from executing successfully. For example, if logical processor PO reads line A in a transactional region and another 
logical processor P1 writes A (either inside or outside a transactional region) then logical processor PO may abort if 
logical processor P1’s write interferes with processor PO's ability to execute transactionally. Similarly, if PO writes 
line Ain a transactional region and Pireads or writes A (either inside or outside a transactional region), then PO 
may abort if Pi's access to A interferes with PO's ability to execute transactionally. In addition, other coherence 
traffic may at times appear as conflicting requests and may cause aborts. While these false conflicts may happen, 
they are expected to be uncommon. The conflict resolution policy to determine whether PO or P1 aborts in the 
above scenarios is implementation specific. 
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CHAPTER 17 
INTEL® MEMORY PROTECTION EXTENSIONS 


NOTE 
Intel® MPX has been deprecated and is not available on all future processors. 


FAL INTEL*° MEMORY PROTECTION EXTENSIONS (INTEL® MPX) 


Intel® Memory Protection Extensions (Intel® MPX) is a new capability introduced into Intel Architecture. Intel 
MPX can increase the robustness of software when it is used in conjunction with compiler changes to check mem- 
ory references, for those references whose compile-time normal intentions are usurped at runtime due to buffer 
overflow or underflow. Two of the most important goals of Intel MPX are to provide this capability at low perfor- 
mance overhead for newly compiled code, and to provide compatibility mechanisms with legacy software com- 
ponents. A direct benefit Intel MPX provides is hardening software against malicious attacks designed to cause 
or exploit buffer overruns. This chapter describes the software visible interfaces of this extension. 


17.2 INTRODUCTION 


Intel MPX is designed to allow a system (i.e., the logical processor(s) and the OS software) to run both Intel MPX 
enabled software and legacy software (written for processors without Intel MPX). When executing software 
containing a mixture of Intel MPX-unaware code (legacy code) and Intel MPX-enabled code, the legacy code does 
not benefit from Intel MPX, but it also does not experience any change in functionality or reduction in performance. 
The performance of Intel MPX-enabled code running on processors that do not support Intel MPX may be similar to 
the use of embedding NOPs in the instruction stream. 


Intel MPX is designed such that an Intel MPX enabled application can link with, call into, or be called from legacy 
software (libraries, etc.) while maintaining existing application binary interfaces (ABIs). And in most cases, the 
benefit of Intel MPX requires minimal changes to the source code at the application programming interfaces (APIs) 
to legacy library/applications. As described later, Intel MPX associates bounds with pointers in a novel manner, 
and the Intel MPX hardware uses bounds to check that the pointer based accesses are suitably constrained. Intel 
MPX enabled software is not required to uniformly or universally utilize the new hardware capabilities over all 
memory references. Specifically, programmers can selectively use Intel MPX to protect a subset of pointers. 


The code enabled for Intel MPX benefits from memory protection against vulnerability such as buffer overrun. 
Therefore there is a heightened incentive for software vendors to adopt this technology. At the same time, the 
security benefit of Intel MPX-protection can be implemented according to the business priorities of software 
vendors. A software vendor can choose to adopt Intel MPX in some modules to realize partial benefit from Intel MPX 
quickly, and introduce Intel MPX in other modules in phases (e.g. some programmer intervention might be required 
at the interface to legacy calls). This adaptive property of Intel MPX is designed to give software vendors control on 
their schedule and modularity of adoption. It also allows a software vendor to secure defense for higher priority or 
more attack-prone software first; and allows the use of Intel MPX features in one phase of software engineering 
(e.g., testing) and not in another (e.g., general release) as dictated by business realities. 


The initial goal of Intel MPX is twofold: (1) provide means to defend a system against attacks that originate 
external to some trust perimeter where the trust perimeter subsumes the system memory and integral data repos- 
itories, and (2) provide means to pinpoint accidental logic defects in pointer usage, by undergirding memory refer- 
ences with hardware based pointer validation. 


As with any instruction set extensions, Intel MPX can be used by application developers beyond detecting buffer 
overflow, the processor does not limit the use of Intel MPX for buffer overflow detection. 
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17.3. INTELMPX PROGRAMMING ENVIRONMENT 


Intel MPX introduces new bounds registers and new instructions that operate on bounds registers. Intel MPX 
allows an OS to support user mode software (operating at CPL=3) and supervisor mode software (CPL < 3) to add 
memory protection capability against buffer overrun. It provides controls to enable Intel MPX extensions for user 
mode and supervisor mode independently. Intel MPX extensions are designed to allow software to associate 
bounds with pointers, and allow software to check memory references against the bounds associated with the 
pointer to prevent out of bound memory access (thus preventing buffer overflow).The bounds registers hold lower 
bound and upper bound that can be checked when referencing memory. An out-of-bounds memory reference then 
causes a #BR exception. Intel MPX also introduces configuration facilities that the OS must manage to support 
enabling of user-mode (and/or supervisor-mode) software operations using bounds registers. 


17.3.1 Detection and Enumeration of Intel MPX Interfaces 


Detection of hardware support for processor extended state component is provided by the main CPUID leaf func- 
tion ODH with index ECX = 0. Specifically, the return value in EDX:EAX of CPUID.(EAX=0DH, ECX=0) provides a 
64-bit wide bit vector of hardware support of processor state components. 


If CPUID.(EAX=07H,ECX=0H):EBX.MPX[bit 14] = 1 (the processor supports Intel MPX), 
CPUID.(EAX=0DH,ECX=0):EAX[bits 4:3] will enumerate the XSAVE state components associated with Intel MPX. 
These two component states of Intel MPX are the following: 


° BNDREGS: CPUID.(EAX=0DH,ECX=0):EAX[3] indicates XCRO.BNDREGS[bit 3] is supported. This bit indicates 
bound register component of Intel MPX state, comprised of four bounds registers, BNDO-BND3 (see Section 
17.3.2). 


¢ BNDCSR: CPUID.(EAX=0DH,ECX=0):EAX[4] indicates XCRO.BNDCSR[bit 4] is supported. This bit indicates 
bounds configuration and status component of Intel MPX comprised of BNDCFGU and BNDSTATUS. OS must 
enable both BNDCSR and BNDREGS bits in XCRO to ensure full Intel MPX support to applications. 


° The size of the processor state component, enabled by XCRO.BNDREGS, is enumerated by 
CPUID.(EAX=0DH,ECX=03H).EAX[31:0] and the byte offset of this component relative to the beginning of the 
XSAVE/XRSTOR area is reported by CPUID.(EAX=0DH, ECX=03H).EBX[31:0]. 


° The size of the processor state component, enabled by XCRO.BNDCSR, is enumerated by 
CPUID.(EAX=0DH,ECX=04H).EAX[31:0] and the byte offset of this component relative to the beginning of the 
XSAVE/XRSTOR area is reported by CPUID.(EAX=0DH, ECX=04H).EBX[31:0]. 


On processors that support Intel MPX, CPUID.(EAX=0DH,ECX=0):EAX[3] and CPUID.(EAX=0DH,ECX=0):EAX[4] 
will both be 1. On processors that do not support Intel MPX, CPUID.(EAX=0DH,ECX=0):EAX[3] and 
CPUID.(EAX=0DH,ECX=0):EAX[4] will both be 0. 


The layout of XCRO for extended processor state components defined in Intel Architecture is shown in Figure 2-8 of 
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. 


Enabling Intel MPX requires an OS to manage bits [4:3] of XCRO; see Section 13.5. 


The BNDLDX and BNDSTX instructions (Section 17.4.3) each take an operand whose bits are used to traverse data 
structures in memory. In 64-bit mode, these instructions operate only on the lower bits in the supplied 64-bit 
addresses. The number of bits used is 48 plus a value called the MPX address-width adjust (MAWA). The MAWA 
value depends on CPL: 


° If CPL < 3, the supervisor MAWA (MAWAS) is used. This value is 0. 


e If CPL = 3, the user MAWA (MAWAU) is used. The value of MAWAU is enumerated in 
CPUID.(EAX=07H,ECX=0H):ECX.MAWAU[bits 21:17]. 


(Outside of 64-bit mode, BNDLDX and BNDSTX use the entire 32 bits of the supplied linear-address operands.) 


17.3.2 | Bounds Registers 


Intel MPX Architecture defines four new registers, BNDO-BND3, which Intel MPX instructions operate on. Each 
bounds register stores a pair of 64-bit values which are the lower bound (LB) and upper bound (UB) of a buffer, see 
Figure 17-1. 


17-2 Vol. 1 


INTEL® MEMORY PROTECTION EXTENSIONS 


127 64 63 0 
Upper Bound (UB) Lower Bound (LB) 


Figure 17-1. Layout of the Bounds Registers BNDO-BND3 


The bounds are unsigned effective addresses, and are inclusive. The upper bounds are architecturally represented 
in 1/’s complement form. Lower bound = 0, and upper bound = 0 (1's complement of all 1s) will allow access to the 
entire address space. The bounds are considered as INIT when both lower and upper bounds are 0 (cover the 
entire address space). The two Intel MPX instructions which operate on the upper bound (BNDMK and BNDCU) 
account for the 1’s complement representation of the upper bounds. 


The instruction set does not impose any conventions on the use of bounds registers. Software has full flexibility 
associating pointers to bounds registers including sharing them for multiple pointers. 


RESET or INIT# will initialize (write zero to) BNDO-BND3. 


17.3.3 Configuration and Status Registers 


Intel MPX defines two configuration registers and one status register. The two configuration registers are defined 
for user mode (CPL = 3) and supervisor mode (CPL < 3). The user-mode configuration register BNDCFGU is acces- 
sible only with the XSAVE feature set instructions. 


The supervisor mode configuration register is an MSR, referred to as IA32_BNDCFGS (MSR OD90H). Because both 
configuration registers share a common layout (see Figure 17-2), when describing the common behavior, these 
configuration registers are often denoted as BNDCFGx, where x can be U or S, for user and supervisor mode 
respectively. 


63 12 11 21 0 


Base of Bound Directory (Linear Address) Reserved (must be zero) En 


Bprv: BNDPRESERVE | | 
En: Enable 


Figure 17-2. Common Layout of the Bound Configuration Registers BNDCFGU and BNDCFGS 


The Enable bit in BNDCFGU enables Intel MPX in user mode (CPL = 3), and the Enable bit in BNDCFGS enables Intel 
MPX in supervisor mode (CPL < 3). The BNDPRESERVE bit controls the initialization behavior of CALL/RET/JMP/Jcc 
instructions without the BND (F2H) prefix -- see Section 17.5.3. 


WRMSR to BNDCFGS will #GP if any of the reserved bits of BNDCFGS is not zero or if the base address of the bound 
directory is not canonical. XRSTOR of BNDCFGU ignores the reserved bits and does not fault if any is non-zero; 
similarly, it ignores the upper bits of the base address of the bound directory and sign-extends the highest imple- 
mented bit of the linear address to guarantee the canonicality of this address. 


Intel MPX also defines a status register (BNDSTATUS) primarily used to communicate status information for #BR 
exception. The layout of the status register is shown in Figure 17-3. 
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63 210 


ABD: Address Bound Directory Entry - Linear Address 


EC: Error Code 


Figure 17-3. Layout of the Bound Status Registers BNDSTATUS 


The BNDSTATUS register provides two fields to communicate the status of Intel MPX operations: 


° EC (bits 1:0): The error code field communicates status information of a bound range exception #BR or 
operation involving bound directory. 


¢ ABD: (bits 63:2):The address field of a bound directory entry can provide information when operation on the 
bound directory caused a #BR. 


The valid error codes are defined in Table 17-1. 


Table 17-1. Error Code Definition of BNDSTATUS 
EC Description Meaning 


00b! No Intel MPX exception | No exception caused by Intel MPX operations. 
#BR caused by BNDCL, BNDCU or BNDCN instructions; 


01b Bounds violation ABD is 0. 
: #BR caused by BNDLDX or BNDSTX instructions, ABD will be set to the linear address of the 
10b Invalid BD entry nana : 
invalid bound-directory entry 
11b Reserved Reserved 
NOTES: 


1. When legacy BOUND instruction cause a #BR with Intel MPX enabled (see Section 17.5.4), EC is written with 
Zero. 


RESET or INIT# will set BNDCFGx and BNDSTATUS registers to zero. 


17.3.4 Read and Write of IA32_BNDCFGS 


The RDMSR and WRMSR instructions can be used to read and write the IA32_BNDCFGS MSR. (The XSAVE state 
does not include IA32_BNDCFGS, and instructions in the XSAVE feature set do not access that register). Attempts 
to write to IA32_BNDCFGS check for canonicality of the addresses being loaded into IA32_BNDCFGS (regardless of 
mode at the time of execution) and will #GP if the address is not canonical or if reserved bits would be set. 


Software can use RDMSR and WRMSR to read and write IA32_BNDCFGS as long as the processor implements Intel 
MPX, i.e. CPUID.(EAX=07H, ECX=0H).EBX.MPX = 1. The states of CR4 and XCRO have no impact on the ability to 
access IA32_BNDCFGS. 


17.4 INTEL MPX INSTRUCTION SUMMARY 
When Intel MPX is not enabled or not present, all Intel MPX instructions behave as NOP. There are eight Intel MPX 
instructions, Table 17-2 provides a summary. 


A C/C++ compiler can implement intrinsic support for Intel MPX instructions to facilitate pointer operation with 
capability of checking for valid bounds on pointers. Typically, Intel MPX intrinsics are implemented by compiler via 
inline code generation where bounds register allocations are handled by the compiler without requiring the 
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programmer to directly manipulate any bounds registers. Therefore no new data type for a bounds register is 
needed in the syntax of Intel MPX intrinsics. 


Table 17-2. Intel MPX Instruction Summary 


Intel MPX 


Instruction Description 
BNDMK b, m Create LowerBound (LB) and UpperBound (UB) in the bounds register b 
BNDCL b, r/m Checks the address of a memory reference or address in r against the lower bound 
BNDCU b, r/m Checks the address of a memory reference or address in r against the upper bound in 1’s complement form 
BNDCN b, r/m Checks the address of a memory reference or address in r against the upper bound not in 1’s complement 


form 


BNDMOV b, b/m Copy/load LB and UB bounds from memory or a bounds register 


BNDMOV b/m, b Store LB and UB bounds in a bounds register to memory or another register 


BNDLDX b, mib Load bounds using address translation using an sib-addressing expression mib 


BNDSTX mib, b Store bounds using address translation using an sib-addressing expression mib 


17.4.1 Instruction Encoding 

All Intel MPX instructions are NOP on processors that report CPUID.(EAX=07H, ECX=0H).EBX.MPX [bit 14] = 0, or 
if Intel MPX is not enabled by the operating system (see Section 13.5). Applications can selectively opt-in to use 
Intel MPX instructions. 


All Intel MPX opcodes encoded to operate on BNDO-BND3 are valid Intel MPX instructions. All Intel MPX opcodes 
encoded to operate on bound registers beyond BND3 will #UD if Intel MPX is enabled. 


BNDLDX/BNDSTX opcodes require 66H as a mandatory prefix with its operand size tied to the address size attri- 
bute of the supported operating modes. Attempt to override operand size attribute with 66H or with REX.W in 64- 
bit mode is ignored. 


17.4.2 Usage and Examples 


BNDMkK is typically used after memory is allocated for a buffer, e.g., by functions such as malloc, calloc, or when 
the memory is allocated on the stack. However, many other usages are possible such as when accessing an array 
member of a structure. 


Example 17-1. BNDMK Example Usage in Application and Library Code 


int A[100]; //assume the array A is allocated on the stack at ‘offset’ | // similarly, for a library implementation of dynamic allocated 
from RBP. memory 
// the instruction to store starting address of array will be: int * k = malloc(100); 

LEA RAX, [RBP+offset] // assuming that malloc returns pointer k in RAX and holds (size 
// the instruction to create the bounds for array A will be: - 1) in RCX 

BNDMK BNDO, [RAX+399] // the malloc implementation will execute the following 
// Store RAX into BNDO.LB, and ~(RAX+399) into BNDO.UB. instruction before returning: 

BNDMK BNDO, [RAX+RCX] 
// BNDO.LB stores RAX, and BNDO.UB stores ~(RAX+RCX) 


BNDMOV is typically used to copy bounds from one bound register to another when a pointer is copied from one 
general purpose register to another, or to spill/fill bounds into memory corresponding to a spill/fill of a pointer. 


Example 17-2. BNDMOV Example 


Spilling or caller save of bound register would use BNDMOV [RBP+ offset], BNDx. 


Assuming that the calling convention is that bound of first pointer is passed in BNDO, and that bound happens to be in BND3 before 
the call, the software will add instruction BNDMOV BNDO, BND3 prior to the call. 
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BNDCL/BNDCU/BNDCN are typically used before writing to a buffer but can be used in other instances as well. If 
there are no bounds violations as a result of bound check instruction, the processor will proceed to execute the next 
instruction. However, if the bound check fails, it will signal #BR exception (fault). 

Typically, the pointer used to write to memory will be compared against lower bound. However, for upper bound 
check, the software must add the (operand size - 1) to the pointer before upper bound checking. 

For example, the software intend to write 32-bit integer in 64-bit mode into a buffer at address specified in RAX, 
and the bounds are in register BNDO, the instruction sequence will be: 


BNDCL BNDO, [RAX] 
BNDCU BNDO, [RAX+3] ; operand size is 4 
MOV Dword ptr [RAX], RBX ; RBX has the data to be written to the buffer. 


Software may move one of the two bound checks out of a loop if it can determine that memory is accessed strictly 
in ascending or descending order. For string instructions of the form REP MOVS, the software may choose to do 
check lower bound against first access and upper bound against last access to memory. However, if software wants 
to also check for wrap around conditions as part of address computation, it should check for both upper and lower 
bound for first and last instructions (total of four bound checks). 


BNDSTX is used to store the bounds associated with a buffer and the “pointer value” of the pointer to that buffer 
onto a bound table entry via address translation using a two-level structure, see Section 17.4.3. 
For example, the software has a buffer with bounds stored in BNDO, the pointer to the buffer is in ESI, the following 
sequence will store the “pointer value” (the buffer) and the bounds into a configured bound table entry using 
address translation from the linear address associated with the base of a SIB-addressing form consisting of a base 
register and a index register: 

MOV ECX, Dword ptr [ESI] ; store the pointer value in the index register ECX 

MOV EAX, ESI ; store the pointer in the base register EAX 


BNDSTX Dword ptr [EAX+ECX], BNDO ; perform address translation from the linear address of the base 
EAX and store bounds and pointer value ECX onto a bound table entry. 


Similarly to retrieve a buffer and its associated bounds from a bound table entry: 
MOV EAX, dword ptr [EBX] ; 


BNDLDX BNDO, dword ptr [EBX+EAX]; perform address translation from the linear address of the base EBX, 
and loads bounds and pointer value from a bound table entry 


17.4.3. Loading and Storing Bounds in Memory 


Intel MPX defines two instructions to load and store of the linear address of a pointer to a buffer, along with the 
bounds of the buffer into a data structure of extended bounds. When storing these extended bounds, the processor 
parses the address of the pointer (where it is stored) to locate an entry in a bound table in which to store the 
extended bounds. Loading of an extended bounds performs the reverse sequence. 


The memory representation of an extended bound is a 4-tuple consisting of lower bound, upper bound, pointer 
value and a reserved field (for use by future versions of Intel MPX; software must not use this field). Accesses to 
these extended bounds use 32-bit or 64-bit operands according to the current paging mode. Thus, a bound table 
entry is 4*64 bits (32 bytes) in 64-bit mode and 4*32 bits (16 bytes) outside 64-bit mode The linear address of a 
bound table is stored in a bound-directory entry (BDE). The linear address of the bound directory is derived from 
either BNDCFGU (CPL = 3) or BNDCFGS (CPL < 3). 


The bound directory and bound tables are stored in application memory and are allocated by the application (in 
case of kernel use, the structures will be in kernel memory). The bound directory and each bound table are in 
contiguous linear memory. 


Software should take care to allocate sufficient memory for the bound directory and the bound tables. The amount 
of memory required depends on the current operating mode and, in some cases, on CPL: 


° In 64-bit mode: 
— Each bound table comprises 2!” 32-byte entries thus, the size of a bound table in 64-bit mode is 4 MBytes. 
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The size of the bound directory depends on the value of MAWA. Specifically, the bound directory comprises 
228+MAWA 64-bit entries; thus, the size of a bound directory in 64-bit mode is 2!*™4WA GBytes. The value 
of MAWA depends on CPL: 


¢ If CPL < 3, the supervisor MAWA (MAWAS) is used. This value is 0. Thus, when CPL < 3, a bound 
directory comprises 228 64-bit entries and the size of a bound directory is 2 GBytes. 


¢ If CPL = 3, the user MAWA (MAWAU) is used. The value of MAWAU is enumerated in 
CPUID.(EAX=07H,ECX=0H):ECX.MAWAU[bits 21:17]. When CPL = 3, a bound directory comprises 
228+MAWAU 64-bit entries and the size of a bound directory is 2!*MAWAU GBytes. 


NOTE 


Software operating with CPL = 3 in 64-bit mode should use CPUID to determine the proper amount 
of memory to allocate for the bound directory. 


® Outside 64-bit mode: 


Each bound table comprises 2!9 16-byte entries; thus, the size of a bound table outside 64-bit mode is 
16 KBytes. 


— The bound directory comprises 22° 32-bit entries; thus, the size of a bound directory outside 64-bit mode 


Bounds 


is 4 MBytes. This size is independent of MAWA and CPL. 
in memory are associated with the memory address where the pointer is stored, i.e., Ap. A linear address 


LAp is computed by adding the appropriate segment base to Ap. (Note: for these instructions, the segment over- 
ride applies only to the computation.) Section 17.4.3.1 and Section 17.4.3.2 describe how BNDLDX and BNDSTX 

parse LAp to locate a bound-directory entry (BDE), which contains the address of a bound table, and then a bound- 
table entry (BTE), which contains the extended bounds for the pointer. 


17.4.3.1 | BNDLDX and BNDSTX in 64-Bit Mode 


Figure 17-4 shows the two-level structures for address translation of extended bounds in 64-bit mode. 


63 


BNDCFGU/BNDCFGS 
63 12 11 0 
Base of Bound Directory (Linear Address) 


Pe 0 


BNDCFGx[63:12] 0 


Linear Address of “pointer” (LAp) 
63 47+MAWA 20 19 3 0 


30+MAWA 


LAp[47+MAWA:20] LAp[19:3] 
“| Reserved 24 
/ Pointer Value | 16 
64 22 / Upper Bound 
31+MAWA / Lower Bound 


Ve 
Bound Table Entries | = —~ 


Bound Directory Entries 61 
> > 0 
Bound Table (4 MBytes) 


0 
Bound Directory (21*MAWA GBytes) 


Figure 17-4. Bound Paging Structure and Address Translation in 64-Bit Mode 
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As noted earlier, the linear address of the bound directory is derived from either BNDCFGU (CPL = 3) or BNDCFGS 
(CPL < 3). In 64-bit mode, each bound-directory entry (BDE) is 8 bytes. The number of entries in the bound direc- 
tory is deer’ yoy the MPX address-width adjust (MAWA; see Section 17.3.1). Specifically, the number of 
entries is 228+MA 


In 64-bit mode, the processor uses the two-level structures to access extended bounds as follows: 


A bound directory is located at the 4-KByte aligned linear address specified in bits 63:12 of BNDCFGx (see 
Figure 17-2). A bound directory comprises 228+™AWA 64-bit entries (BDEs); thus, the size of a bound directory 
in 64-bit mode is 2!+MAWA GBytes. A BDE is selected using the LAp (linear address of pointer to a buffer) to 
construct a 64-bit offset as follows: 


— bits 63:31+MAWA are 0; 

— bits 30+MAWA:3 are LAp[47+MAWA:20]; and 

— bits 2:0 are O. 

The address of the BDE is the sum of the bound-directory base address (from BNDCFGx) plus this 64-bit offset. 


Bit O of a BDE is a valid bit. If this bit is 0, use of the BDE by BNDLDX or BNDSTX causes #BR, sets 
BNDSTATUS[1:0] to 10b (the error code), and loads BNDSTATUS[63:2] with bits 63:2 of the linear address of 
the BDE. Otherwise, the processor uses bits 63:3 of the BDE as the 8-byte aligned address of a bound table 
(BT); the processor ignores bits 2:1 of a BDE. 


A bound table comprises 2!” 32-byte entries (BTEs); thus, the size of a bound table in 64-bit mode is 4 MBytes. 
A BTE is selected using the LAp (linear address of pointer to a buffer) to construct an offset as follows: 


— bits 21:5 are LAp[19:3]; and 

— bits 4:0 are O. 

The address of the BTE is the sum of the bound-table base address (from the BDE) plus this offset. 
Each BTE comprises the following: 

— a 64-bit lower bound (LB) field; 

— a 64-bit upper bound (UB) field; 

— a 64-bit pointer value; and 

— a 64-bit reserved field. This field is reserved for future Intel MPX; software must not use it. 


17.4.3.2 |BNDLDX and BNDSTX Outside 64-Bit Mode 
Figure 17-5 shows the two-level structures for address translation of extended bounds outside 64-bit mode. 


As noted earlier, the linear address of the bound directory is derived from either BNDCFGU (CPL = 3) or BNDCFGS 
(CPL < 3). Outside 64-bit mode, each bound-directory entry (BDE) is 4 bytes. The number of entries in the bound 
directory is 22° 


Outside 64-bit mode, the processor uses the two-level structures to access extended bounds as follows: 


A bound directory is located at the 4-KByte aligned linear address specified in bits 31:12 of BNDCFGx (see 
Figure 17-2). A bound directory comprises 27° 32-bit entries (BDEs); thus, the size of a bound directory outside 
64-bit mode is 4 MBytes. A BDE is selected using the LAp (linear address of pointer to a buffer) to construct an 
offset as follows: 


— bits 21:2 are LAp[31:12]; and 
— bits 1:0 are O. 
The address of the BDE is the sum of the bound-directory base address (from BNDCFGx) plus this offset. 


Bit O of a BDE is a valid bit. If this bit is 0, use of the BDE by BNDLDX or BNDSTX causes #BR, sets 
BNDSTATUS[1:0] to 10b (the error code), and loads BNDSTATUS[31:2] with bits 31:2 of the linear address of 
the BDE. Otherwise, the processor uses bits 31:2 of the BDE as the 4-byte aligned address of a bound table 
(BT); the processor ignores bit 1 of a BDE. 
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BNDCFGU/BNDCFGS 
31 12 11 0 
Base of Bound Directory (Linear Address) 


31 eas 0 


BNDCFGx[31:12] 0 
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Figure 17-5. Bound Paging Structure and Address Translation Outside 64-Bit Mode 


A bound table comprises 2!° 16-byte entries (BTEs); thus, the size of a bound table outside 64-bit mode is 
16 KBytes. A BTE is selected using the LAp (linear address of pointer to a buffer) to construct an offset as 
follows: 


bits 13:4 are LAp[11:2]; and 
bits 3:0 are 0. 


The address of the BTE is the sum of the bound-table base address (from the BDE) plus this offset. This address 
is use as an offset into the DS segment to determine the linear address of the BTE. 


¢ Each BTE comprises the following: 


17.5 


a 32-bit lower bound (LB) field; 
a 32-bit upper bound (UB) field; 
a 32-bit pointer value; and 


a 32-bit reserved field. This field is reserved for future Intel MPX; software must not use it. 


INTERACTIONS WITH INTEL MPX 


17.5.1. Intel MPX and Operating Modes 


In 64- 


bit Mode, all Intel MPX instructions use 64-bit operands for bounds and 64 bit addressing, i.e. REX.W & 67H 


have no effect on data or address size. 


XSAVE, XSAVEOPT and XRSTOR load/store 64-bit values in all modes, as these state-management instructions are 
not Intel MPX instructions. 
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In compatibility and legacy modes (including 16-bit code segments, real and virtual 8086 modes) all Intel MPX 
instructions use 32-bit operands for bounds and 32 bit addressing. The upper 32-bits of destination bound register 
are cleared (consistent with behavior of integer registers) 


In 32-bit and compatibility mode, the bounds are 32-bit, and are treated same as 32-bit integer registers. There- 
fore, when 32-bit bound is updated in a bound register, the upper 32-bits are undefined. When switching from 64- 
bit, the behavior of content of bounds register will be similar to that of general purpose registers. 


Table 17-3 describes the impact of 67H prefix on memory forms of Intel MPX instructions (register-only forms 
ignore 67H prefix) when Intel MPX is enabled: 


Table 17-3. Effective Address Size of Intel MPX Instructions with 67H Prefix 


Addressing Mode 67H Prefix Effective Address Size used for Intel MPX instructions when Intel MPX is enabled 
64-bit Mode Y 64 bit addressing used 
64-bit Mode N 64 bit addressing used 
32-bit Mode Y #UD 
32-bit Mode N 32 bit addressing used 
16-bit Mode Y 32 bit addressing used 
16-bit Mode N #UD 


17.5.2 — Intel MPX Support for Pointer Operations with Branching 
Intel MPX provides flexibility in supporting pointer operation across control flow changes. Intel MPX allows 


* compatibility with legacy code that may perform pointer operation across control flow changes and are unaware 
of Intel MPX, along with 


¢ Intel MPX-aware code that adds bounds checking protection to pointer operation across control flow changes. 
The interface to provide such flexibility consists of: 

¢ Using a prefix, referred to as BND prefix, to relevant branch instructions: CALL, RET, JMP and Jcc 

¢ BNDCFGU and BNDCFGS provides the bit field, BNDPRESERVE (bit 1). 


The value of BNDPRESERVE in conjunction with the presence/absence the BND prefix with those branching instruc- 
tion will determine whether the values in BNDO-BND3 will be initialized or unchanged. 


17.5.3 CALL, RET, JMP and All Jcc 


An application compiled to use Intel MPX will use the REPNE (F2H) prefix (denoted by BND) for all forms of near 
CALL, near RET, near JMP, short & near Jcc instructions (BND+CALL, BND+RET, BND+JMP, BND+Jcc). See Table 
17-4 for specific opcodes. All far CALL, RET and JMP instructions plus short JMP (JMP rel 8, opcode EB) instructions 
will never cause bound registers to be initialized. 


If BNDPRESERVE bit is one, above instructions will NOT INIT the bounds registers when BND prefix is not present 
for above instructions (legacy behavior). However, If BNDPRESERVE is zero, above instructions will INIT ALL bound 
registers (BNDO-BND3) when BND prefix is not present for above instructions. If BND prefix is present for above 
instructions, the BND registers will NOT INIT any bound registers (BNDO-BND3). 


The legacy code will continue to use non-prefixed forms of these instructions, so if BNDPRESERVE is zero, all the 
bound registers will INIT by legacy code. This allows the legacy function to execute and return to callee with all 
bound registers initialized (legacy code by definition cannot make or load bounds in bound registers because it does 
not have Intel MPX instructions). This will eliminate compatibility concerns when legacy function might have 
changed the pointer in registers but did not update the value of the bounds registers associated with these 
pointers. 


If BNDCFGx.BNDPRESERVE is clear then non-prefixed forms of these instructions will initialize all the bound regis- 
ters. If this bit is set then non-prefixed and prefixed forms of these instructions will preserve the contents of bound 
registers as shown in Table 17-4. 
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Table 17-4. Bounds Register INIT Behavior Due to BND Prefix with Branch Instructions 
Instruction Branch Instruction Opcodes BNDPRESERVE = 0 BNDPRESERVE = 1 
CALL E8, FF/2 Init BNDO-BND3 BNDO-BND3 unchanged 
BND + CALL F2 €8, Fe FF/2 BNDO-BND3 unchanged BNDO-BND3 unchanged 
RET C2, C3 Init BNDO-BND3 BNDO-BND3 unchanged 
BND + RET F2 C2, F2 C3 BNDO-BND3 unchanged BNDO-BND3 unchanged 
JMP E9, FF/4 Init BNDO-BND3 BNDO-BND3 unchanged 
BND + JMP F2 E9, F2 FF/4 BNDO-BND3 unchanged BNDO-BND3 unchanged 
Jec i he aie - ue Init BNDO-BND3 BNDO-BND3 unchanged 
BND + Jcc - i A foe i A ge _| BNDO-BND3 unchanged BNDO-BND3 unchanged 


17.5.4 BOUND Instruction and Intel MPX 


If Intel MPX in enabled (see Section 13.5) and a #BR was caused due to a BOUND instruction, then BOUND instruc- 
tion will write zero to the BNDSTATUS register. In all other situations, BOUND instruction will not modify 
BNDSTATUS. Specifically, the operation of the BOUND instruction can be described as: 
IF (( BOUND instruction caused #BR) AND ( CR4.0XXSAVE =1 AND XCRO.BNDREGS=1 AND XCRO.BNDCSR =1) AND 

((CPL=3 AND BNDCFGU.ENABLE = 1) OR (CPL < 3 AND BNDCFGS.ENABLE = 1) ) ) THEN 

BNDSTATUS := 0; 
ELSE 

BNDSTATUS is not modified; 
Fl; 


17.5.5 Programming Considerations 


Intel MPX instruction set does not dictate any calling convention, but allows the calling convention extensions to be 
interoperable with legacy code by making use of the of the bound registers and the bound tables to convey argu- 
ments and return values. 


17.5.6 — Intel MPX and System Management Mode 


Upon delivery of an SMI to a processor supporting Intel MPX, the contents of IA32_BNDCFGS is saved to SMM state 
save map (at offset 7EDOH) and the register is then cleared when entering into SMM. RSM restores IA32_BNDCFGS 
from the SMM state save map. The instruction forces the reserved bits (11:2) to 0 and sign-extends the highest 
implemented bit of the linear address to guarantee the canonicality of this address (regardless of what is in SMM 
state save map). 


The content of IA32_BNDCFGS is cleared after entering into SMM. Thus, Intel MPX is disabled inside an SMM 
handler until SMM code enables it explicitly. This will prevent initialization of the bound registers by execution of 
CALL, RET, JMP, or Jcc in SMM code. 


17.5.7. Support of Intel MPX in VMCS 

A new guest-state field for IA32_BNDCFGS is added to the VMCS. In addition, two new controls are added: 
° a VM-exit control called “clear BNDCFGS” 

¢ aVM-entry control called “load BNDCFGS.” 
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VM exits always save IA32_BNDCFGS into BNDCFGS field of VMCS; if “clear BNDCFGS” is 1, VM exits clear 
IA32_BNDCFGS. If “load BNDCFGS” is 1, VM entry loads IA32_BNDCFGS from VMCS. If loading IA32_BNDCFGS, 
VM entry should check the value of that register in the guest-state area of the VMCS and cause the VM entry to fail 
(late) if the value is one that would causes WRMSR to fault if executed in ring 0. 


17.5.8 Support of Intel MPX in Intel TSX 


For some processor implementations, the following Intel MPX instructions may always cause transactional aborts: 


¢ An Intel TSX transaction abort will occur in case of legacy branch (that causes bounds registers INIT) when at 
least one bounds register was in a NON-INIT state. 


¢ An Intel TSX transaction abort will occur in case of a BNDLDX & BNDSTX instruction on non-flat segment. 


Intel MPX Instructions (including BND prefix + branch instructions) not enumerated above as causing transactional 
abort when used inside a transaction will typically not cause an Intel TSX transaction to abort. 
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CHAPTER 18 
CONTROL-FLOW ENFORCEMENT TECHNOLOGY (CET) 


18.1 INTRODUCTION 


Return-oriented programming (ROP), and similarly CALL/JMP-oriented programming (COP/JOP), have been the 
prevalent attack methodologies for stealth exploit writers targeting vulnerabilities in programs. These attack meth- 
odologies have the common elements: 


¢ Acode module with execution privilege and contain small snippets of code sequence with the characteristic: at 
least one instruction in the sequence being a control transfer instruction that depends on data either in the 
return stack or in a register for the target address. 


* Diverting the control flow instruction (e.g., RET, CALL, JMP) from its original target address to a new target (via 
modification in the data stack or in the register). 


Control-Flow Enforcement Technology (CET) provides the following capabilities to defend against ROP/COP/JOP 
style control-flow subversion attacks: 


¢ Shadow stack: Return address protection to defend against ROP. 
® Indirect branch tracking: Free branch protection to defend against COP/JOP. 


Both capabilities introduce new instruction set extensions, and are described in the Inte/® 64 and IA-32 Architec- 
tures Software Developer’s Manual, Volumes 2A, 2B, 2C & 2D. 


Control-Flow Enforcement Technology introduces a new exception (#CP) with interrupt vector 21. 


18.1.1 Shadow Stack 


A shadow stack is a second stack for the program that is used exclusively for control transfer operations. This stack 
is separate from the data stack and can be enabled for operation individually in user mode or supervisor mode. 
When shadow stacks are enabled, the CALL instruction pushes the return address on both the data and shadow 
stack. The RET instruction pops the return address from both stacks and compares them. If the return addresses 
from the two stacks do not match, the processor signals a control protection exception (#CP). Note that the 
shadow stack only holds the return addresses and not parameters passed to the call instruction. 


The shadow stack is protected from tamper through the page table protections such that regular store instructions 
cannot modify the contents of the shadow stack. To provide this protection the page table protections are extended 
to support an additional attribute for pages to mark them as “Shadow Stack” pages. When shadow stacks are 
enabled, control transfer instructions/flows like near call, far call, call to interrupt/exception handlers, etc. store 
return addresses to the shadow stack and the access will fault if the underlying page is not marked as a “Shadow 
Stack” page. However stores from instructions like MOV, XSAVE, etc. will not be allowed. Likewise control transfer 
instructions like near RET, far RET, IRET, etc. when they attempt to read from the shadow stack the access will fault 
if the underlying page is not marked as a “Shadow Stack” page. This paging protection detects and prevents condi- 
tions that cause an overflow or underflow of the shadow stack when the shadow stack is delimited by non-shadow 
stack guard pages, or any malicious attempts to redirect the processor to consume data from addresses that are 
not shadow stack addresses. 


18.1.2 — Indirect Branch Tracking 


The ENDBRANCH instruction is a new instruction that is used to mark valid jump target addresses of indirect calls 
and jumps in the program. This instruction opcode is selected to be one that is a NOP on legacy machines such that 
programs compiled with ENDBRANCH new instruction continue to function on old machines without the CET 
enforcement. On processors that support CET the ENDBRANCH is still a NOP and is primarily used as a marker 
instruction by the processor pipeline to detect control flow violations. The CPU implements a state machine that 
tracks indirect JMP and CALL instructions. When one of these instructions is executed, the state machine moves 
from IDLE to WAIT_FOR_ENDBRANCH state. In WAIT_FOR_ENDBRANCH state the next instruction in the program 
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stream must be an ENDBRANCH. If the next instruction is not an ENDBRANCH, the processor causes a control 
protection exception (#CP); otherwise, the state machine moves back to IDLE state. 


18.1.3. Speculative Behavior when CET is Enabled 


Speculative execution of near indirect JMP/CALL/RET indirect branches may be able to create an active side channel 
vulnerability that reveals the contents of data. 


There are two basic methods that an attacker may be able to use to control indirect branch speculation in order to 
speculatively execute code that causes a side channel: 


1. Attacker controlled prediction. 
2. Attacker controlled jump redirection. 


With attacker controlled prediction, the attacker trains indirect branch predictors such that the desired victim indi- 
rect branch goes to the attacker desired location. Examples include Branch Target Injection (also called “Variant 2” 
and “Spectre”) and RSB wrap on underflow (also called “ret2spec”). 


With attacker controlled jump redirection, the attacker controls a speculative-only value used as input to the indi- 
rect branch so that the branch mispredicts to the attacker desired location. Examples of this include Bound Check 
Bypass Store (where a speculative store containing an attacker controlled value may overwrite the indirect branch 
target before the load of the target) and Speculative Store Bypass (where a load of the indirect branch target may 
bypass the most recent store of the target value and thus speculatively read an older attacker controlled value at 
the same memory location). 


In addition to the existing mitigation features like IBRS, STIBP and IBPB, processors supporting CET will have a 
variety of additional features to constrain control flow speculation in order to mitigate such attacks. For details on 
these features, see Section 18.2.6, “Constraining Execution at Targets of RET” and Section 18.3.8, “Constraining 
Speculation after Missing ENDBRANCH”. 


18.2 SHADOW STACKS 


A shadow stack is a second expand down stack used exclusively for control transfer operations. This stack is sepa- 
rate from the data stack. The shadow stack is not used to store data and hence is not explicitly writeable by soft- 
ware. Writes to the shadow stack are restricted to control transfer instructions and shadow stack management 
instructions. The shadow stack feature can be enabled separately in user mode (CPL == 3) or supervisor mode 
(CPL < 3). 


Shadow stacks operate only in protected mode. Shadow stacks cannot be enabled in virtual 8086 mode. 


It is recommended to not configure the shadow stack in the linear address range 0 to 64 KB or adjacent to the 
canonical address boundary. 


18.2.1 Shadow Stack Pointer and its Operand and Address Size Attributes 


When CET is enabled the processor supports a new architectural register, shadow stack pointer (SSP), when the 
processor supports the shadow stack feature. The SSP cannot be directly encoded as a source, destination or 
memory operand in instructions. The SSP points to the current top of the shadow stack. 


The width of the shadow stack is 32-bit in 32-bit/compatibility mode and is 64-bit in 64-bit mode. The address-size 
attribute of the shadow stack is likewise 32-bit in 32-bit/compatibility mode and 64-bit in 64-bit mode. 


18.2.2 Terminology 


When shadow stacks are enabled, certain control transfer instructions/flows and shadow stack management 
instructions do loads/stores to the shadow stack. Such load/stores from control transfer instructions and shadow 
stack management instructions are termed as shadow_stack_load and shadow_stack_store to distinguish them 
from a load/store performed by other instructions like MOV, XSAVES, etc. 
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The pseudocode for the instruction operations use the notation ShadowStackEnabled(CPL) as a test of whether 
shadow stacks are enabled at the CPL. This term returns a TRUE or FALSE indication as follows. 
ShadowStackEnabled(CPL): 
IF CR4.CET = 1 AND CRO.PE = 1 AND EFLAGS.VM = 0 
IF CPL=3 
THEN 
(* Obtain the shadow stack enable from IA32_U_CET MSR (MSR address GAOH) used to enable 
feature for CPL = 3 *) 
SHADOW_STACK_ENABLED = IA32_U_CET.SH_STK_EN; 
ELSE 
(* Obtain the shadow stack enable from I[A32_S_CET MSR (MSR address 6A2H) used to enable 
feature for CPL < 3 *) 
SHADOW_STACK_ENABLED = IA32_S_CET.SH_STK_EN; 


Fl; 
IF SHADOW_STACK_ENABLED = 1 
THEN 
return TRUE; 
ELSE 
return FALSE; 
Fl; 
ELSE 


(* Shadow stacks not enabled in real mode and virtual-8086 mode or if the master CET feature 
enable in CR4 is disabled *) 
return FALSE; 
ENDIF 


Additionally, the following terms are used. 


¢ ShadowStackPush4B: Decrements the shadow stack pointer (SSP) by 4 bytes and copies the 4 byte source 
operand to the top of the shadow stack. 


¢ ShadowStackPush8B : Decrements the shadow stack pointer (SSP) by 8 bytes and copies the 8 byte source 
operand to the top of the shadow stack. 


¢ ShadowStackPop4B: Copies 4 bytes at the current top of stack (indicated by the SSP register) to the location 
specified with the destination operand. It then increments the SSP register by 4 bytes to point to the new top 
of stack. 


¢ ShadowStackPop8B: Copies 8 bytes at the current top of stack (indicated by the SSP register) to the location 
specified with the destination operand. It then increments the SSP register by 8 bytes to point to the new top 
of stack. 


° shadow_stack_lock_cmpxchg8B(address, new_value, expected_value): this function executes atomically and 
compares the expected_value to the 8 byte read from memory specified by the address operand using a locked 
shadow_stack_load. If the two values are equal, the new_value is written to memory specified by the address 
operand using a locked shadow_stack_store. If the two values are not equal, then the value read by the locked 
shadow_stack_load is written back. The memory specified by the address operand receives a write cycle 
without regard to the result of the comparison. The function returns the value read from the memory specified 
by the address operand. 


18.2.3 Supervisor Shadow Stack Token 


On an inter-privilege far CALL or when calling an interrupt/exception handler at a higher privilege level, a stack 
switch occurs; if shadow stacks are enabled at the new privilege level, then a shadow stack switch occurs. Shadow 
stacks that can be switched to by hardware as part of a privilege change are required to have a supervisor shadow 
stack token set up by the supervisor to provide the address of the new SSP register. The supervisor shadow stack 
tokens also serve the purpose of enforcing that a shadow stack can be made active on only one logical processor 
when switched to by the processor. The supervisor shadow stack token must be set up only on shadow stacks 
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intended to be used on these transfers. The address of the supervisor shadow stack token is programmed into the 
IA32_PLx_SSP MSR (where 0 < x § 2). The WRMSR and XRSTORS instructions require the address specified in the 
IA32_PLx_SSP MSR (where 0 < x < 2) to be 4 byte aligned; otherwise, the instruction causes a general protection 
exception (#GP(0)). 


The supervisor shadow stack token is a 64-bit value formulated as follows. 

° Bit 63:3: Bits 63:3 of the linear address of the supervisor shadow stack token. 
¢ Bit 2: Reserved. Must be zero. 

¢ Bit 1: Reserved. Must be zero. 


° Bit O: Busy bit. If 0, indicates this shadow stack is not active on any logical processor. If 1, indicates this shadow 
stack is currently active on one of the logical processors. 


The following figure illustrates a supervisor shadow stack with a supervisor shadow stack token located at its base. 


<Next push saves here> 


ad OxFF8 | busy 


IA32_PLx_SSP = OxFF8 


Figure 18-1. Supervisor Shadow Stack with a Supervisor Shadow Stack Token 


The 8-byte supervisor shadow stack token and the 24-byte stack frame pushed on the shadow stack after the 
token is acquired must be fully contained within a 32-byte region that is aligned to 32-bytes on the shadow stack. 
If they are not, a general-protection exception (#GP(0)) occurs. While the accesses to the token may cause faults, 
VM exits, or data breakpoints, the subsequent pushes of the remaining 24 bytes should not. 


The processor does the following checks prior to switching to a supervisor shadow stack programmed into the 
IA32_PLx_SSP MSR. These steps are performed atomically. 


1. Load the supervisor shadow stack token from the address specified in the IA32_PLx_SSP MSR using a 
shadow_stack_load. 


Check if the busy bit in the token is 0; reserved bits must be 0. 


Check if the address programmed in the MSR matches the address in the supervisor shadow stack token; 
reserved bits must be 0. 


4. If checks 2 and 3 are successful, then set the busy bit in the token using a shadow_stack_store and switch the 
SSP to the value specified in the IA32_PLx_SSP MSR. 


5. If checks 2 or 3 fail, then the busy bit is not set and a #GP(0) exception is raised. 


On a far RET to a lesser privilege level or on an IRET that switches shadow stack, the instruction clears the busy bit 
in the shadow stack token as follows. These steps are also performed atomically. 


1. Load the supervisor shadow stack token from the SSP using a shadow_stack_load. 

2. Check if the busy bit in the token is 1; reserved bits must be 0. 

3. Check if the address programmed in supervisor shadow stack token matches SSP; reserved bits must be 0. 
4 


If checks 2 and 3 are successful, then clear the busy bit in the token using a shadow_stack_store; else continue 
without modifying the contents of the shadow stack pointed to by SSP. 
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18.2.4 Shadow Stack Usage on Task Switch 


A task switch (see Chapter 7, “Task Management” in the Inte/® 64 and IA-32 Architectures Software Developer’s 
Manual, Volume 3A) may be invoked by: 


¢ IMP or CALL instruction to a TSS descriptor in the GDT. 
¢  JMP or CALL instruction to a task-gate descriptor in the GDT or the current LDT. 
¢ An interrupt or exception vector points to a task-gate descriptor in the IDT. 


With shadow stack enabled, the new task must be associated with a 32-bit TSS and must not be in virtual-8086 
mode. The 32-bit SSP for the new task is located at offset 104 in the 32-bit TSS. Thus the TSS of the new task must 
be at least 108 bytes. This SSP is required to be 8 byte aligned, and required to point to a “supervisor shadow 
stack” token (though the task may be at CPL3). 


On a task switch initiated by a CALL instruction, an interrupt, or exception, the SSP of the old task is pushed onto 
the shadow stack of the new task along with the CS and LIP of the old task. This is true even for a nested task 
switch initiated by a CALL instruction. Likewise, on a task switch initiated by IRET, the SSP of the new task is 
restored from the shadow stack of old task. The CS and LIP on the shadow stack of the old task are matched 
against the return address determined by the CS and EIP of the new task. If the match fails, a #CP(FAR-RET/IRET) 
exception is reported. 


18.2.5 Switching Shadow Stacks 


The architecture provides a mechanism to switch shadow stacks using a pair of instructions; RSTORSSP and SAVE- 
PREVSSP. The RSTORSSP instruction verifies a shadow-stack-restore token located at the top of the new shadow 
stack and referenced by the memory operand of this instruction. After RSTORSSP determines the validity of the 
restore point on the new shadow stack, it switches the SSP to point to the token. The shadow-stack-restore token 
is a 64-bit value formatted as follows. 


¢ Bit 63:2: Value of shadow stack pointer when this restore point was created. 
¢ Bit 1: Reserved. Must be zero. 


° Bit 0: Mode bit. If 0, the token is a compatibility/legacy mode shadow-stack-restore token. If 1, then this 
shadow stack restore token can be used with a RSTORSSP instruction in 64-bit mode. 


The shadow-stack-restore token is created by the SAVEPREVSSP instruction. The operating system may also 
create a restore point on a shadow stack by creating a shadow-stack-restore token. 


Once the shadow stack has been switched to a new shadow stack by the RSTORSSP instruction, software can 

create a restore point on the old shadow stack by executing the SAVEPREVSSP instruction. In order to allow the 

SAVEPREVSSP instruction to determine the address where to save the shadow-stack-restore token, the RSTORSSP 

instruction replaces the shadow-stack-restore token with a previous-ssp token that holds the value of the SSP at 

the time the RSTORSSP instruction was invoked. The previous-ssp token is formatted as follows. 

¢ ~=Bit 63:2: Shadow stack pointer when the RSTORSSP instruction was invoked, i.e., the SSP of the old shadow 
stack. 


° Bit 1: Set to 1. 


¢ Bit 0: Mode bit. If 0, then this previous-ssp token can be used with a SAVEPREVSSP instruction in compati- 
bility/legacy mode. If 1, then this previous-ssp token can be used with a SAVEPREVSSP instruction in 64-bit 
mode. 


The following figure illustrates the RSTORSSP instruction operation during a shadow stack switching sequence. 
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Current Recluse New Shadow 
Shadow Stack si i a Stack 
FF8H 4000H |0|M/3FF8H SSP————»|1000H | 1|M 
1000H 4000H 
Current active shadow stack Shadow stack to switch to State following successful 


RSTORSSP 


Figure 18-2. RSTORSSP to Switch to New Shadow Stack 


In this example, the initial SSP is 1000H and the shadow-stack-restore token is on a new shadow stack at address 
3FF8H. The token at address 3FF8H holds the SSP when this restore point was created; in this example it is 4000H. 


In order to switch to the new shadow stack, the RSTORSSP instruction is invoked with the memory operand 
pointing set to 3FF8H. When the RSTORSSP instruction completes, the SSP is set to 3FF8H and the shadow-stack- 
restore token at 3FF8H is replaced by a previous-ssp token that holds the address 1000H, i.e., the old SSP. 


The following figure illustrates the SAVEPREVSSP instruction operation during a shadow stack switching sequence. 


New Shadow Previous New Shadow 
Stack Shadow Stack Stack 
ssp ————>|1000H | 1 | M} 3FF8H 1000H | 1 | M/| 3FF8H 
4000H SSP ———_> 4000H 
Current active shadow stack “shadow stack restore” token Current active shadow stack 
with a “previous SSP” token pushed on previous shadow with a “previous SSP” token 
stack following popped off 


SAVEPREVSSP 


Figure 18-3. SAVEPREVSSP to Save a Restore Point 


To allow switching back to this old shadow stack, a SAVEPREVSSP instruction is now invoked. The SAVEPREVSSP 

instruction does not take any memory operand and expects to find a previous-ssp token at the top of the shadow 
stack, i.e., at address 3FF8H. The SAVEPREVSSP instruction then saves a shadow-stack-restore token on the old 

shadow stack at address FF8H, and the token itself holds the address 1000H which is the address recorded in the 
previous-ssp token. The SAVEPREVSSP instruction also pops the previous-ssp token off the current shadow stack 
and thus the SSP following SAVEPREVSSP is 4000H. 


Subsequently to switch back to the old shadow stack, a RSTORSSP instruction may be invoked with memory 
operand set to FF8H. 


If, following a switch to a new shadow stack, it is not required to create a restore point on the old shadow stack, 
then the previous-ssp token created by the RSTORSSP instruction can be popped off the shadow stack by using the 
INCSSP instruction. 


See the SAVEPREVSSP and RSTORSSP instruction operations for the detailed algorithm. 
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18.2.6 Constraining Execution at Targets of RET 


Instructions at the target of a RET instruction will not execute, even speculatively, if the RET addresses (either from 
normal stack or shadow stack) are speculative-only or do not match, unless the target of the RET is also predicted 
(e.g., by a Return Stack Buffer prediction), when CET shadow stack is enabled. A RET address would be specula- 
tive-only if it was modified by an older speculative-only store, or was an older value than the most recent value 
stored to that address on the logical processor. 


18.3. INDIRECT BRANCH TRACKING 


When the indirect branch tracking feature is active, the indirect JMP/CALL instruction behavior changes as follows. 


¢ IMP: If the next instruction retired after an indirect JMP is not an ENDBR32 instruction in legacy and compati- 
bility mode, or ENDBR64 instruction in 64-bit mode, then a #CP fault is generated. Below JMP instructions are 
tracked to enforce an ENDBRANCH. Note that Jcc, RIP relative, and far direct JMP are not included as these 
have an offset encoded into the instruction and are not exploitable to create unintended control transfers. 


— JMPr/m16, JMP r/m32, JMP r/m64 
— JMP m16:16, JMP m16:32, JMP m16:64 


° CALL: If the next instruction retired after an indirect CALL is not an ENDBR32 instruction in legacy and compat- 
ibility mode, or ENDBR64 in 64-bit mode, then a #CP fault is generated. Below CALL instructions are tracked to 
enforce an ENDBRANCH. Note that relative and zero displacement forms of CALL instructions are not included 
as these have an offset encoded into the instruction and are not exploitable to create unintended control 
transfers. 


— CALL r/m16, CALL r/m32, CALL r/m64 
— CALL m16:16, CALL m16:32, CALL m16:64 


The ENDBR32 and ENDBR64 instructions will have the same effect as the NOP instruction on Intel 64 processors 
that do not support CET. On processors supporting CET, these instructions do not change register or flag state. This 
allows CET instrumented programs to execute on processors that do not support CET. Even when CET is supported 
and enabled, these NOP-like instructions do not affect the execution state of the program, do not cause any addi- 
tional register pressure, and are minimally intrusive from power and performance perspectives. 


The processor implements two dual-state machines to track indirect CALL/JMP for terminations. One state machine 
is maintained for user mode and one for supervisor mode. At reset the user and supervisor mode state machines 
are in IDLE state. 


On instructions other than indirect CALL/JMP, the state machine stays in the IDLE state. 
On an indirect CALL or JMP instruction, the state machine transitions to the WAIT_FOR_ENDBRANCH state. 


In the WAIT_FOR_ENDBRANCH state, the indirect branch tracking state machine verifies the next instruction is an 
ENDBR32 instruction in legacy and compatibility mode, or ENDBR64 instruction in 64-bit mode, and either: 


° Causes a #CP fault, or 
¢ Allows the next instruction if legacy compatibility configuration allows (see Section 18.3.6). 
The priority of the #CP(ENDBRANCH) exception relative to other events is as follows. 
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#CP Fault 


Indirect CALL/JMP, RET >) Target Instruction 


NMI 


Hardware Interrupts / Probe 


RESET / #MC 


TSS Trap /PEBS/ BTS/ VAPIC Trap 
Code Breakpoint 


CS Limit Violation / Code Page Fault 
#UD / #NM (Decode Faults) 


SIPI / STOPCLK/ LTCYC/ SMI / INIT 


Figure 18-4. Priority of Control Protection Exception on Missing ENDBRANCH 


Higher priority faults/traps/events that occur at the end of an indirect CALL/JMP are delivered ahead of any 
#CP(ENDBRANCH) fault. The CET state machine at the privilege level where the higher priority fault/trap/event 
occurred retains its state when the control transfers to the fault/trap/event handler. The instruction pointer pushed 
on the stack for a #CP(ENDBRANCH) fault is the address of the instruction at the target of the indirect CALL/JMP 
that caused the fault. 


18.3.1 No-track Prefix for Near Indirect CALL/JMP 


CET allows software to designate certain indirect CALL and JMP instructions as “non-tracked indirect control 
transfer instructions”. Software (e.g., compiler generated code for switch statements, jump tables, etc.) should use 
the no-track prefix only if they have generated code to validate the possible targets of this CALL/JMP to be legal 
targets. Software (e.g., compilers), when using the no-track prefix with CALL/JMP where an absolute offset is spec- 
ified indirectly in a memory location, should ensure that such memory locations cannot be tampered. When 
enabled by setting the NO_TRACK_EN control in the IA32_U_CET/IA32_S_CET MSR, near indirect CALL and JMP 
instructions when prefixed with 3EH do not modify the CET indirect branch tracker. Far CALL and JMP instructions 
are always tracked and ignore the 3EH prefix. When this control is 0, near indirect CALL and JMP instructions are 
always tracked irrespective of the presence of the 3EH prefix. 


In 64-bit mode, the 3EH prefix on an indirect CALL or JMP is recognized as a no-track prefix if there isn’t a 64H/65H 
prefix on the instruction. 


In legacy/compatibility mode, the 3EH prefix on an indirect CALL or JMP is recognized as a no-track prefix when it 
is the last group 2 prefix on the instruction. 
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18.3.2 Terminology 


The pseudocode for the instruction operations use a notation EndbranchEnabled(CPL) as a test of whether indirect 


branch tracking is enabled at the CPL. This term returns a TRUE or FALSE indication as follows. 


EndbranchEnabled(CPL): 
IF CR4.CET = 1 AND CRO.PE = 1 AND EFLAGS.VM = 0 
IF CPL = 3 


THEN 
(* Obtain the ENDBRANCH enable from MSR used to enable feature for CPL = 3 *) 


ENDBR_ENABLED = IA32_U_CET.ENDBR_EN; 
ELSE 
(* Obtain the ENDBRANCH enable from MSR used to enable feature for CPL < 3 *) 
ENDBR_ENABLED = IA32_S_CET.ENDBR_EN; 
Fl; 
IF ENDBR_ENABLED = 1 
THEN 
return TRUE; 
ELSE 
return FALSE; 
Fl; 
ELSE 
(* Indirect branch tracking is not enabled in real mode and virtual-8086 mode or if the master CET feature 
enable in CR4 is disabled *) 
return FALSE; 
ENDIF 


Likewise the notation EndbranchEnabledAndNotSuppressed is defined as follows: 


EndbranchEnabledAndNotSuppressed(CPL): 
IF CR4.CET = 1 AND CRO.PE = 1 AND EFLAGS.VM = 0 
IF CPL = 3 


THEN 
(* Obtain the ENDBRANCH enable from MSR used to enable feature for CPL = 3 *) 


ENDBR_ENABLED = IA32_U_CET.ENDBR_EN; 
SUPPRESSED = IA32_U_CET.SUPPRESS; 


ELSE 
(* Obtain the ENDBRANCH enable from MSR used to enable feature for CPL < 3 *) 


ENDBR_ENABLED = IA32_S_CET.ENDBR_EN; 
SUPPRESSED = IA32_S_CET.SUPPRESS; 
Fl; 
IF ENDBR_ENABLED = 1 AND SUPPRESSED = 0 
THEN 
return TRUE; 
ELSE 
return FALSE; 
Fl; 


ELSE 
(* Indirect branch tracking is not enabled in real mode and virtual-8086 mode or if the master CET feature 


enable in CR4 is disabled *) 
return FALSE; 
ENDIF 
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18.3.3 Indirect Branch Tracking 


The hardware implements two CET indirect branch tracker state machines, one for user mode (CPL == 3) and one 
for supervisor mode (CPL < 3). At any time, which of the CET indirect branch trackers is in the active state depends 
on the CPL of the machine. When a user space program is executing, the CPL 3 CET indirect branch tracker is 
active. When supervisor mode software is executing, the CPL < 3 tracker is active. This section describes the 
various control transfer conditions and the tracker state on those transfers. 


18.3.3.1 Control Transfers between CPL 3 and CPL < 3 


Some events and instructions can cause control transfer to occur from CPL 3 to CPL < 3, and vice versa. As part of 
the CPL change the hardware also switches the active CET indirect branch tracker. For example, when an interrupt 
occurs during execution of a user mode (CPL == 3) program and it causes the CPL to switch to supervisor mode 
(CPL < 3) then, as part of the CPL change, the user mode CET indirect branch tracker becomes inactive and the 
supervisor mode CET indirect branch tracker becomes active. A subsequent IRET is used by the interrupt handler 
to return to the interrupted user mode program. This IRET causes the processor to switch the CPL to user mode 
(CPL ==3) and, as part of the CPL change, the supervisor mode CET indirect branch tracker becomes inactive and 
the user mode CET indirect branch tracker becomes active. 


The CPL where the event or instruction that caused the control transfer occurs is termed the source CPL, and the 
CET indirect branch tracker state at that CPL is referred here as the source CET indirect branch tracker state. The 
CPL reached at the end of the control transfer is termed the destination CPL, and the CET indirect branch tracker 
state at that CPL is referred to as the destination CET indirect branch tracker state. 


This section describes various cases of control transfers that occur between user mode (CPL 3) and supervisor 
mode (CPL < 3). 


In all these cases the source CET indirect branch tracker state becomes not active and retains its state (IDLE, 
WAIT_FOR_ENDBRANCH), and the target CET indirect branch tracker state becomes active if there was no fault 
during the transfer. 


°® Case 1: Far CALL/JMP, SYSCALL/SYSENTER 


— If indirect branch tracking is enabled, the target indirect branch tracker state becomes active and is unsup- 
pressed and goes to WAIT_FOR_ENDBRANCH. This enforces that the subroutine invoked by a far CALL/JMP 
must begin with an ENDBRANCH. 


® Case 2: Hardware interrupt/trap/exception/NMI/Software interrupt/Machine Checks 


— If indirect branch tracking is enabled, the target indirect branch tracker state becomes active and is unsup- 

pressed and goes to WAIT_FOR_ENDBRANCH. 
® Case 3: IRET/Far RET 

— If indirect branch tracking enabled, the target indirect branch tracker becomes active and keeps its state. If 
the user mode was interrupted by a higher priority event, like an interrupt at the end of the indirect 
CALL/JMP, then when an IRET or Far RET is used to return to the interrupted user mode program, the user 
mode indirect branch tracker retains its state and a #CP fault will occur if the next instruction decoded is not 
an ENDBR32/64 according to mode of machine. 


18.3.3.2 Control Transfers within CPL 3 or CPL < 3 


Some events and instructions can cause control transfer to occur within CPL 3 or CPL < 3. For such transfers since 
the CPL class does not change, the same indirect branch tracker is used at the beginning and end of the control 
transfer. 


© Case 1: Far CALL/JMP, Near indirect CALL/JMPCALL/JMP 


— Far CALL/JMP: If indirect branch tracking is enabled, active indirect branch tracker is unsuppressed and 
goes to WAIT_FOR_ENDBRANCH. 


— Near indirect CALL/JMPCALL/JMP: If indirect branch tracking is enabled and not suppressed, active indirect 
branch tracker goes to WAIT_FOR_ENDBRANCH. 


® Case 2: Hardware interrupt/trap/exception/NMI/Software interrupt/Machine Checks 
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— If indirect branch tracking is enabled, the active indirect branch tracker is unsuppressed and goes to 


WAIT_FOR_ENDBRANCH. 
° Case 3: IRET 


— If indirect branch tracking is enabled, the active indirect branch tracker keeps its state. 


18.3.4 


Indirect Branch Tracking State Machine 


The state machine is described by Table 18-1. 


Table 18-1. Indirect Branch Tracking State Machine 


Current State 


Trigger 


Next State 


TRACKER=IDLE, SUPPRESS=0, 
ENDBR_EN=1 


Instructions other than indirect CALL/|MP or 
3€H prefixed near indirect CALL/JMP and 
NO_TRACK_EN=1 


TRACKER=IDLE, SUPPRESS=0, 
ENDBR_EN=1 


Indirect CALL/JMP without 3EH prefix 
Indirect CALL/JMP with 3EH prefix and 
NO_TRACK_EN=0 

Far CALL/JMP 


TRACKER=WAIT_FOR_ENDBRANCH, SUP- 
PRESS=0, ENDBR_EN=1 


TRACKER= WAIT_FOR_ENDBRANCH, SUP- 
PRESS=0, ENDBR_EN=1 


INT3/INT1 


TRACKER= WAIT_FOR_ENDBRANCH, SUP- 
PRESS=0, ENDBR_EN=1 


ENDBRANCH instruction 


TRACKER=IDLE, SUPPRESS=0, 
ENDBR_EN=1 


Successful ENCLU[ERESUME] 


TRACKER=IDLE, SUPPRESS=0, 
ENDBR_EN=1 


Instructions other than ENDBRANCH, suc- 
cessful ENCLU[ERESUME] or INT3 or INT1 


If legacy compatibility treatment is not 

enabled or if not allowed by legacy code 

page bitmap: 

« No state change and deliver #CP 
(ENDBRANCH) 

If legacy compatibility treatment is 

enabled and transfer allowed by legacy 

code page bitmap: 

* TRACKER=IDLE, 
SUPRESS=!SUPPRESS_DIS, 
ENDBR_EN=1 


TRACKER=x, SUPPRESS=x, ENDBR_EN=0O 


TRACKER=IDLE, SUPPRESS=1, 


All instructions 


Far CALL/JMP, INTn/INT3/INTO 


TRACKER=x, SUPPRESS=x, ENDBR_EN=0 


TRACKER=WAIT_FOR_ENDBRANCH, SUP- 
PRESS=0, ENDBR_EN=1 


ENDBRANCH instruction 


TRACKER=IDLE, SUPPRESS=0, 


and is disallowed as a valid state by 
WRMSR/XRSTORS/VM entry/VM exit) 


ENDBR_EN=1 Successful ENCLU[ERESUME] ENDBR_EN=1 
All other instructions including indirect TRACKER=IDLE, SUPPRESS=1, 
CALL/JMP ENDBR_EN=1 

TRACKER=1, SUPPRESS=1, ENDBR_EN=1 

(This state cannot be reached by hardware NA NA 
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18.3.5  INT3 Treatment 


INT3 are treated special in the WAIT_FOR_ENDBRANCH state. Occurrence of INT3 do not move the tracker to IDLE 
but instead the #BP trap from the INT3 instructions respectively is delivered as a higher priority event than the #CP 
exception due to missing ENDBRANCH. 


Inside an enclave, INT3 delivers a fault-class exception and thus does not require the CPL to be less than DPL in the 
IDT gate 3. Following opt-out entry, the instruction delivers #UD. Following opt-in entry, INT3 delivers #BP. The 
special treatment of INT3 in WAIT_FOR_ENDBRANCH state does not apply in enclave mode following opt-out entry. 


18.3.6 Legacy Compatibility Treatment 


ENDBRANCH legacy compatibility treatment allows a CET enabled program to be used with legacy software that 
was not compiled / instrumented with ENDBRANCH. A CET enabled program enters legacy compatibility treatment 
when all of the below conditions are met. 


1. Legacy compatibility configuration is enabled in this CPL class by setting the LEG_IW_EN bit in 
IA32_U_CET/IA32_S_CET. 


2. Control transfer is performed using an indirect CALL/JMP without no-track prefix to an instruction other than 
ENDBRANCH. 


3. The legacy code page bitmap is setup to indicate that the target of the control transfer is a legacy code page. 


The legacy code page bitmap is a data structure in program memory that is used by the hardware to determine if 
the code page to which a legacy transfer is being performed is allowed. The access rights for accessing the legacy 
code page bitmap is determined by the current privilege level (CPL). The legacy code page bitmap is expected to 
be setup as a read-only data structure. 


When a matching ENDBRANCH instruction is not decoded at the target of an indirect CALL/JMP when required, the 
processor performs the below actions. 
CET indirect branch tracking state machine violation event handler: 
If LEG_IW_EN == 
LA = LIP; 
IF ENCLAVE_MODE == 
LA = LA - SECS.BASEADDR; 
ENDIF 
(* Load byte from bitmap. Address-size attribute for this load is 64 bits if IA32_EFER.LMA is 1 and is 32 bits when IA32_EFER.LMA 
is O*) 
IF (IA32_EFER.LMA & CS.L) == 
BITMAP_BYTE = load 1 byte from address (BITMAP_BASE + LA[31:15]) 
ELSE IF (CR4.LA57 == 0) 
BITMAP_BYTE = load 1 byte from address (BITMAP_BASE + LA[47:15]) 
ELSE 
BITMAP_BYTE = load 1 byte from address (BITMAP_BASE + LA[56:15]) 


Fl; 
IF BITMAP_BYTE & (1 << LA[14:12]) == 0 then Deliver #CP(ENDBRANCH) fault 
IF CPL = 3 
IA32_U_CET.TRACKER = IDLE 
IA32_U_CET.SUPPRESS = IA32_U_CET.SUPPRESS_DIS == 0? 1:0 
ELSE 
IA32_S_CET.TRACKER = IDLE 
IA32_S_CET.SUPPRESS = IA32_S_CET.SUPPRESS_DIS == 0? 1:0 
ENDIF 


Restart the instruction (handle all arch. consistency around MOV SS state machines, STI etc.) without 
opening up interrupt/trap window. 

ELSE 
Deliver #CP(ENDBRANCH) Fault 
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ENDIF 


Faults/traps in pseudocode are delivered normally (e.g., #PF, EPT violation). On a fault, the active tracker holds the 
last value (WAIT_FOR_ENDBRANCH) and the address saved on the stack is the current IP (instruction that wasn’t 
the ENDBRANCH). 


The CET indirect branch tracking state machine is suppressed in legacy compatibility mode if the SUPPRESS_DIS 
control bit is 0. 


Once the CET indirect branch tracking state machine has been suppressed, subsequent indirect CALL/JMP are not 
tracked for termination instruction. 


Once CET indirect branch tracking has been suppressed, subsequent execution of ENDBRANCH instructions will do 
the following (see the ENDBR32 and ENDBR64 instructions in the Intel® 64 and IA-32 Architectures Software 
Developer’s Manual, Volume 2A for details). 


IF EndbranchEnabled(CPL) == 


NOP 
ELSE 
SUPPRESS = 0 
TRACKER = IDLE 
ENDIF 


18.3.6.1 Legacy Code Page Bitmap Format 


The legacy code page bitmap is a flat bitmap whose linear address is pointed to by the EB_LEG_BITMAP_BASE. 
Each bit in the bitmap represents a 4K page in linear memory. If the bit is 1 it indicates that the corresponding code 
page is a legacy code page; else it is a CET-enabled code page. 


The processor uses the linear address of the instruction to which legacy transfer was attempted to lookup the 
bitmap. Bits of the linear address used as index in the bitmap are as follows. 


¢ In legacy and compatibility mode: Bits 31:12. 
¢ In 64-bit mode (EFER.LMA=1 and CS.L=1): Bits 47:12. 


18.3.7. Other Considerations 


18.3.7.1 Intel® Transactional Synchronization Extensions (Intel® TSX) Interactions 


The XBEGIN instruction encodes the relative offset to the abort handler and hence the fallback to the abort handler 
can be considered as a “direct” branch and the abort handler does not need to have an ENDBRANCH. 


CET continues to enforce indirect CALL/JMP tracking within a transaction. Legacy compatibility treatment inside a 
transaction functions normally. If a transaction abort occurs then the processor sets the state of the indirect branch 
tracker to IDLE and not-suppressed. 


18.3.7.2 #CP(ENDBRANCH) Priority w.r.t #NM and #UD 


#NM, #UD and #CP(ENDBRANCH) are in the same priority class. Both #NM and #UD are opcode based faults. The 
#CP(ENDBRANCH) is prioritized higher than #NM and #UD as CET architecturally requires an ENDBRANCH at 
target of indirect CALL/JMP. 


18.3.7.3. #CP(ENDBRANCH) Priority w.r.t #BP and #DB 


Debug Exceptions priority is as follows. 


¢ Traps delivered before any #CP(ENDBRANCH) fault: Data breakpoint trap, IO breakpoint trap single step trap, 
task switch trap. 


* Code Breakpoint fault detected before instruction decode and delivered before #CP(ENDBRANCH). 
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* General-detect (GD) exception condition fault: Lower priority than #CP(ENDBRANCH). 
® On IRET back from #DB/#BP, the source indirect branch tracker becomes active if enabled and not suppressed. 


INT3 does not cause #CP(ENDBRANCH) to support debugger usage of replacing bytes of ENDBRANCH with INT3 to 
set breakpoints. INT3 at target of a CALL-JMP(indirect) cause #BP(INT3) instead of #CP(ENDBRANCH), 
#CP(ENDBRANCH) fault is delayed. #BP caused by INT3 treated like other events that are higher priority than CET 
fault. On IRET back from #BP the source indirect tracker becomes active if enabled and not suppressed. 


18.3.8 Constraining Speculation after Missing ENDBRANCH 


When the CET tracker is in the WAIT_FOR_ENDBRANCH state, instruction execution will be limited or blocked, even 
speculatively, if the next instruction is not an ENDBRANCH. 


This means that when indirect branch tracking is enabled and not suppressed, the instructions at the target of a 
near indirect JMP/CALL without the no-track prefix will only speculatively execute if there is an ENDBRANCH at the 
target. This can constrain both attacker controlled prediction as well as attacker controlled jump redirection attacks 
on near indirect JMPs/CALLs by reducing the gadgets available to an attacker using these techniques. Early imple- 
mentations of CET may limit the speculative execution to a small number of instructions (less than 8, with no more 
than 5 loads) past a missing ENDBRANCH, while later implementations will completely block the speculative execu- 
tion of instructions after a missing ENDBRANCH. 


This mechanism also limits or blocks speculation of the next sequential instructions after an indirect JMP or CALL, 
presuming the JMP/CALL puts the CET tracker into the WAIT_FOR_ENDBRANCH state and the next sequential 
instruction is not an ENDBRANCH. 


18.4 INTEL® TRUSTED EXECUTION TECHNOLOGY (INTEL® TXT) INTERACTIONS 


GETSEC[ENTERACCS] and GETSEC[SENTER] clear CR4.CET, and it is not restored when these instructions 
complete. 


GETSEC[EXITAC] will cause #GP(0) fault if CR4.CET is set. 
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CHAPTER 19 
INPUT/OUTPUT 


In addition to transferring data to and from external memory, IA-32 processors can also transfer data to and from 
input/output ports (I/O ports). I/O ports are created in system hardware by circuity that decodes the control, data, 
and address pins on the processor. These I/O ports are then configured to communicate with peripheral devices. An 
I/O port can be an input port, an output port, or a bidirectional port. Some I/O ports are used for transmitting data, 
such as to and from the transmit and receive registers, respectively, of a serial interface device. Other I/O ports are 
used to control peripheral devices, such as the control registers of a disk controller. 


This chapter describes the processor’s I/O architecture. The topics discussed include: 
¢ I/O port addressing 

¢ 1/O instructions 

¢ I/O protection mechanism 


19.1. 1/0 PORT ADDRESSING 


The processor permits applications to access I/O ports in either of two ways: 
¢ Through a separate I/O address space 
¢ Through memory-mapped I/O 


Accessing I/O ports through the I/O address space is handled through a set of I/O instructions and a special I/O 
protection mechanism. Accessing I/O ports through memory-mapped I/O is handled with the processor’s general- 
purpose move and string instructions, with protection provided through segmentation or paging. I/O ports can be 
mapped so that they appear in the I/O address space or the physical-memory address space (memory mapped 
I/O) or both. 


One benefit of using the I/O address space is that writes to I/O ports are guaranteed to be completed before the 
next instruction in the instruction stream is executed. Thus, I/O writes to control system hardware cause the hard- 
ware to be set to its new state before any other instructions are executed. See Section 19.6, “Ordering I/O,” for 
more information on serializing of I/O operations. 


19.2 1/0 PORT HARDWARE 


From a hardware point of view, I/O addressing is handled through the processor's address lines. For the P6 family, 
Pentium 4, and Intel Xeon processors, the request command lines signal whether the address lines are being driven 
with a memory address or an I/O address; for Pentium processors and earlier IA-32 processors, the M/IO# pin indi- 
cates a memory address (1) or an I/O address (0). When the separate I/O address space is selected, it is the 
responsibility of the hardware to decode the memory-I/O bus transaction to select I/O ports rather than memory. 
Data is transmitted between the processor and an I/O device through the data lines. 


19.3. I/O ADDRESS SPACE 


The processor's I/O address space is separate and distinct from the physical-memory address space. The I/O 
address space consists of 2!© (64K) individually addressable 8-bit I/O ports, numbered 0 through FFFFH. I/O port 
addresses OF8H through OFFH are reserved. Do not assign I/O ports to these addresses. The result of an attempt 
to address beyond the I/O address space limit of FFFFH is implementation-specific; see the Developer’s Manuals for 
specific processors for more details. 


Any two consecutive 8-bit ports can be treated as a 16-bit port, and any four consecutive ports can be a 32-bit port. 
In this manner, the processor can transfer 8, 16, or 32 bits to or from a device in the I/O address space. Like words 
in memory, 16-bit ports should be aligned to even addresses (0, 2, 4, ...) so that all 16 bits can be transferred ina 
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single bus cycle. Likewise, 32-bit ports should be aligned to addresses that are multiples of four (0, 4, 8, ...). The 
processor supports data transfers to unaligned ports, but there is a performance penalty because one or more 
extra bus cycle must be used. 


The exact order of bus cycles used to access unaligned ports is undefined and is not guaranteed to remain the same 
in future IA-32 processors. If hardware or software requires that I/O ports be written to in a particular order, that 
order must be specified explicitly. For example, to load a word-length I/O port at address 2H and then another word 
port at 4H, two word-length writes must be used, rather than a single doubleword write at 2H. 


Note that the processor does not mask parity errors for bus cycles to the I/O address space. Accessing I/O ports 
through the I/O address space is thus a possible source of parity errors. 


19.3.1 | Memory-Mapped I/O 


I/O devices that respond like memory components can be accessed through the processor’s physical-memory 
address space (see Figure 19-1). When using memory-mapped I/O, any of the processor’s instructions that refer- 
ence memory can be used to access an I/O port located at a physical-memory address. For example, the MOV 
instruction can transfer data between any register and a memory-mapped I/O port. The AND, OR, and TEST 
instructions may be used to manipulate bits in the control and status registers of a memory-mapped peripheral 
device. 


Certain instructions may take an exception or VM exit after completing a memory access (either a read or a write) 
to a memory-mapped I/O address. This exception or VM exit could be due to the instruction performing multiple 
memory accesses (e.g., MOVS, PUSH mem, POP mem, PUSHAD, etc.) or could be due to the ordering of exceptions 
or VM exits within the instruction (e.g., a DIV mem that takes a #DE or a CALL that causes a task switch VM exit). 
If software later re-executes that instruction (e.g., after an IRET or VMRESUME), the MMIO (memory-mapped I/O) 
access may occur again. If the memory-mapped I/O access has a side-effect, that side-effect may be executed 
each time the memory-mapped I/O access occurs. If that is problematic, software must ensure that exceptions or 
VM exits do not occur after accessing the MMIO. 


When using memory-mapped I/O, caching of the address space mapped for I/O operations must be prevented. 
With the Pentium 4, Intel Xeon, and P6 family processors, caching of I/O accesses can be prevented by using 
memory type range registers (MTRRs) to map the address space used for the memory-mapped I/O as uncacheable 
(UC). See Chapter 11, “Memory Cache Control” in the Inte/® 64 and IA-32 Architectures Software Developer’s 
Manual, Volume 3A, for a complete discussion of the MTRRs. 


The Pentium and Intel486 processors do not support MTRRs. Instead, they provide the KEN# pin, which when held 
inactive (high) prevents caching of all addresses sent out on the system bus. To use this pin, external address 
decoding logic is required to block caching in specific address spaces. 


Physical Memory 


FFFF 


EPROM 


I/O Port 
I/O Port 
I/O Port 


0 
Figure 19-1. Memory-Mapped I/O 
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All the IA-32 processors that have on-chip caches also provide the PCD (page-level cache disable) flag in page table 
and page directory entries. This flag allows caching to be disabled on a page-by-page basis. See “Page-Directory 
and Page-Table Entries” in Chapter 4 of in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, 
Volume 3A. 


19.4 I/O INSTRUCTIONS 


The processor’s I/O instructions provide access to I/O ports through the I/O address space. (These instructions 
cannot be used to access memory-mapped I/O ports.) There are two groups of I/O instructions: 


¢ Those that transfer a single item (byte, word, or doubleword) between an I/O port and a general-purpose 
register 


¢ Those that transfer strings of items (strings of bytes, words, or doublewords) between an I/O port and memory 


The register I/O instructions IN (input from I/O port) and OUT (output to I/O port) move data between I/O ports 
and the EAX register (32-bit I/O), the AX register (16-bit I/O), or the AL (8-bit I/O) register. The address of the I/O 
port can be given with an immediate value or a value in the DX register. 


The string I/O instructions INS (input string from I/O port) and OUTS (output string to I/O port) move data 
between an I/O port and a memory location. The address of the I/O port being accessed is given in the DX register; 
the source or destination memory address is given in the DS:ESI or ES:EDI register, respectively. 


When used with the repeat prefix REP, the INS and OUTS instructions perform string (or block) input or output 
operations. The repeat prefix REP modifies the INS and OUTS instructions to transfer blocks of data between an I/O 
port and memory. Here, the ESI or EDI register is incremented or decremented (according to the setting of the DF 
flag in the EFLAGS register) after each byte, word, or doubleword is transferred between the selected I/O port and 
memory. 


See the references for IN, INS, OUT, and OUTS in Chapter 3 and Chapter 4 of the Inte/® 64 and IA-32 Architectures 
Software Developer’s Manual, Volumes 2A & 2B, for more information on these instructions. 


19.5 PROTECTED-MODE I/O 


When the processor is running in protected mode, the following protection mechanisms regulate access to I/O 
ports: 


¢ When accessing I/O ports through the I/O address space, two protection devices control access: 
— The I/O privilege level (IOPL) field in the EFLAGS register 
— The I/O permission bit map of a task state segment (TSS) 


¢ When accessing memory-mapped I/O ports, the normal segmentation and paging protection and the MTRRs 
(in processors that support them) also affect access to I/O ports. See Chapter 5, “Protection” and Chapter 11, 
“Memory Cache Control” in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, 
for a complete discussion of memory protection. 


The following sections describe the protection mechanisms available when accessing I/O ports in the I/O address 
space with the I/O instructions. 


19.5.1 1/0 Privilege Level 


In systems where I/O protection is used, the IOPL field in the EFLAGS register controls access to the I/O address 
space by restricting use of selected instructions. This protection mechanism permits the operating system or exec- 
utive to set the privilege level needed to perform I/O. In a typical protection ring model, access to the I/O address 
space is restricted to privilege levels 0 and 1. Here, the kernel and the device drivers are allowed to perform I/O, 
while less privileged device drivers and application programs are denied access to the I/O address space. Applica- 
tion programs must then make calls to the operating system to perform I/O. 


The following instructions can be executed only if the current privilege level (CPL) of the program or task currently 
executing is less than or equal to the IOPL: IN, INS, OUT, OUTS, CLI (clear interrupt-enable flag), and STI (set 
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interrupt-enable flag). These instructions are called I/O sensitive instructions, because they are sensitive to the 
IOPL field. Any attempt by a less privileged program or task to use an I/O sensitive instruction results in a general- 
protection exception (#GP) being signaled. Because each task has its own copy of the EFLAGS register, each task 
can have a different IOPL. 


The I/O permission bit map in the TSS can be used to modify the effect of the IOPL on I/O sensitive instructions, 
allowing access to some I/O ports by less privileged programs or tasks (see Section 19.5.2, “I/O Permission Bit 
Map”). 


A program or task can change its IOPL only with the POPF and IRET instructions; however, such changes are privi- 
leged. No procedure may change the current IOPL unless it is running at privilege level 0. An attempt by a less priv- 
ileged procedure to change the IOPL does not result in an exception; the IOPL simply remains unchanged. 


The POPF instruction also may be used to change the state of the IF flag (as can the CLI and STI instructions); 
however, the POPF instruction in this case is also I/O sensitive. A procedure may use the POPF instruction to change 
the setting of the IF flag only if the CPL is less than or equal to the current IOPL. An attempt by a less privileged 
procedure to change the IF flag does not result in an exception; the IF flag simply remains unchanged. 


19.5.2 1/0 Permission Bit Map 


The I/O permission bit map is a device for permitting limited access to I/O ports by less privileged programs or 
tasks and for tasks operating in virtual-8086 mode. The I/O permission bit map is located in the TSS (see 

Figure 19-2) for the currently running task or program. The address of the first byte of the I/O permission bit map 
is given in the I/O map base address field of the TSS. The size of the I/O permission bit map and its location in the 
TSS are variable. 


Task State Segment (TSS) 
31 24 23 0 


1 A A ot 


Last byte of 
bitmap must be 
followed by a 


oe ay I/O Permission Bit Map 
I/O map base rE /(O Map Base 64H 
must not 

° S 


exceed DFFFH. 


Figure 19-2. I/O Permission Bit Map 


Because each task has its own TSS, each task has its own I/O permission bit map. Access to individual I/O ports 
can thus be granted to individual tasks. 


If in protected mode and the CPL is less than or equal to the current IOPL, the processor allows all I/O operations 
to proceed. If the CPL is greater than the IOPL or if the processor is operating in virtual-8086 mode, the processor 
checks the I/O permission bit map to determine if access to a particular I/O port is allowed. Each bit in the map 
corresponds to an I/O port byte address. For example, the control bit for I/O port address 29H in the I/O address 
space is found at bit position 1 of the sixth byte in the bit map. Before granting I/O access, the processor tests all 
the bits corresponding to the I/O port being addressed. For a doubleword access, for example, the processors tests 
the four bits corresponding to the four adjacent 8-bit port addresses. If any tested bit is set, a general-protection 
exception (#GP) is signaled. If all tested bits are clear, the I/O operation is allowed to proceed. 
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Because I/O port addresses are not necessarily aligned to word and doubleword boundaries, the processor reads 
two bytes from the I/O permission bit map for every access to an I/O port. To prevent exceptions from being gener- 
ated when the ports with the highest addresses are accessed, an extra byte needs to be included in the TSS imme- 
diately after the table. This byte must have all of its bits set, and it must be within the segment limit. 


It is not necessary for the I/O permission bit map to represent all the I/O addresses. I/O addresses not spanned by 
the map are treated as if they had set bits in the map. For example, if the TSS segment limit is 10 bytes past the 
bit-map base address, the map has 11 bytes and the first 80 I/O ports are mapped. Higher addresses in the I/O 
address space generate exceptions. 


If the I/O bit map base address is greater than or equal to the TSS segment limit, there is no I/O permission map, 
and all I/O instructions generate exceptions when the CPL is greater than the current IOPL. 


19.6 ORDERING I/O 


When controlling I/O devices it is often important that memory and I/O operations be carried out in precisely the 
order programmed. For example, a program may write a command to an I/O port, then read the status of the I/O 
device from another I/O port. It is important that the status returned be the status of the device after it receives 
the command, not before. 


When using memory-mapped I/O, caution should be taken to avoid situations in which the programmed order is 
not preserved by the processor. To optimize performance, the processor allows cacheable memory reads to be 
reordered ahead of buffered writes in most situations. Internally, processor reads (cache hits) can be reordered 
around buffered writes. When using memory-mapped I/O, therefore, it is possible that an I/O read might be 
performed before the memory write of a previous instruction. The recommended method of enforcing program 
ordering of memory-mapped I/O accesses with the Pentium 4, Intel Xeon, and P6 family processors is to use the 
MTRRs to make the memory mapped I/O address space uncacheable; for the Pentium and Intel486 processors, 
either the KEN# pin or the PCD flags can be used for this purpose (see Section 19.3.1, ‘“Memory-Mapped I/O”). 


When the target of a read or write is in an uncacheable region of memory, memory reordering does not occur 
externally at the processor's pins (that is, reads and writes appear in-order). Designating a memory mapped I/O 
region of the address space as uncacheable ensures that reads and writes of I/O devices are carried out in program 
order. See Chapter 11, “Memory Cache Control” in the Inte/® 64 and IA-32 Architectures Software Developer’s 
Manual, Volume 3A, for more information on using MTRRs. 


Another method of enforcing program order is to insert one of the serializing instructions, such as the CPUID 
instruction, between operations. See Chapter 8, “Multiple-Processor Management” in the Inte/® 64 and IA-32 
Architectures Software Developer’s Manual, Volume 3A, for more information on serialization of instructions. 


It should be noted that the chip set being used to support the processor (bus controller, memory controller, and/or 
I/O controller) may post writes to uncacheable memory which can lead to out-of-order execution of memory 
accesses. In situations where out-of-order processing of memory accesses by the chip set can potentially cause 
faulty memory-mapped I/O processing, code must be written to force synchronization and ordering of I/O opera- 
tions. Serializing instructions can often be used for this purpose. 


When the I/O address space is used instead of memory-mapped I/O, the situation is different in two respects: 


¢ The processor never buffers I/O writes. Therefore, strict ordering of I/O operations is enforced by the 
processor. (As with memory-mapped I/O, it is possible for a chip set to post writes in certain I/O ranges.) 


¢ The processor synchronizes I/O instruction execution with external bus activity (see Table 19-1). 
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Table 19-1. 1/0 Instruction Serialization 


Processor Delays Execution of ... Until Completion of ... 
Instruction Being 
Executed Current Instruction? Next Instruction? Pending Stores? Current Store? 
IN Yes Yes 
INS Yes Yes 
REP INS Yes Yes 
OUT Yes Yes Yes 
OUTS Yes Yes Yes 
REP OUTS Yes Yes Yes 
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PROCESSOR IDENTIFICATION AND FEATURE DETERMINATION 


When writing software intended to run on IA-32 processors, it is necessary to identify the type of processor present 
in a system and the processor features that are available to an application. 


20.1 USING THE CPUID INSTRUCTION 


Use the CPUID instruction for processor identification in the Pentium M processor family, Pentium 4 processor 
family, Intel Xeon processor family, P6 family, Pentium processor, and later Intel486 processors. This instruction 
returns the family, model and (for some processors) a brand string for the processor that executes the instruction. 
It also indicates the features that are present in the processor and gives information about the processor’s caches 
and TLB. 


The ID flag (bit 21) in the EFLAGS register indicates support for the CPUID instruction. If a software procedure can 
set and clear this flag, the processor executing the procedure supports the CPUID instruction. The CPUID instruc- 
tion will cause the invalid opcode exception (#UD) if executed on a processor that does not support it. 


To obtain processor identification information, a source operand value is placed in the EAX register to select the 
type of information to be returned. When the CPUID instruction is executed, selected information is returned in the 
EAX, EBX, ECX, and EDX registers. For a complete description of the CPUID instruction, tables indicating values 
returned, and example code, see CPUID—CPU Identification in Chapter 3 of the Inte/® 64 and IA-32 Architectures 
Software Developer’s Manual, Volume 2A. 


20.1.1 Notes on Where to Start 
The following guidelines are among the most important, and should always be followed when using the CPUID 
instruction to determine available features: 


¢ Always begin by testing for the “GenuineIntel,” message in the EBX, EDX, and ECX registers when the CPUID 
instruction is executed with EAX equal to 0. If the processor is not genuine Intel, the feature identification flags 
may have different meanings than are described in Intel documentation. 


° Test feature identification flags individually and do not make assumptions about undefined bits. 


20.1.2 Identification of Earlier IA-32 Processors 


The CPUID instruction is not available in earlier IA-32 processors up through the earlier Intel486 processors. For 
these processors, several other architectural features can be exploited to identify the processor. 


The settings of bits 12 and 13 (IOPL), 14 (NT), and 15 (reserved) in the EFLAGS register are different for Intel’s 32- 
bit processors than for the Intel 8086 and Intel 286 processors. By examining the settings of these bits (with the 
PUSHF/PUSHFD and POPF/POPFD instructions), an application program can determine whether the processor is an 
8086, Intel 286, or one of the Intel 32-bit processors: 


* 8086 processor — Bits 12 through 15 of the EFLAGS register are always set. 

¢ Intel 286 processor — Bits 12 through 15 are always clear in real-address mode. 

° 32-bit processors — In real-address mode, bit 15 is always clear and bits 12 through 14 have the last value 
loaded into them. In protected mode, bit 15 is always clear, bit 14 has the last value loaded into it, and the IOPL 
bits depend on the current privilege level (CPL). The IOPL field can be changed only if the CPL is 0. 

Other EFLAGS register bits that can be used to differentiate between the 32-bit processors: 


¢ Bit 18 (AC) — Implemented only on the Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors. 
The inability to set or clear this bit distinguishes an Intel386 processor from the later IA-32 processors. 


¢ Bit 21 (ID) — Determines if the processor is able to execute the CPUID instruction. The ability to set and clear 
this bit indicates that it is a Pentium 4, Intel Xeon, P6 family, Pentium, or later-version Intel486 processor. 
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To determine whether an x87 FPU or Numeric Processor Extension (NPX) is present in a system, applications can 
write to the x87 FPU status and control registers using the FNINIT instruction and then verify that the correct 
values are read back using the FNSTENV instruction. 


After determining that an x87 FPU or NPX is present, its type can then be determined. In most cases, the processor 
type will determine the type of FPU or NPX; however, an Intel386 processor is compatible with either an Intel 287 
or Intel 387 math coprocessor. 


The method the coprocessor uses to represent - (after the execution of the FINIT, FNINIT, or RESET instruction) 
indicates which coprocessor is present. The Intel 287 math coprocessor uses the same bit representation for +0 
and —co; whereas, the Intel 387 math coprocessor uses different representations for +o and —~~. 
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APPENDIX A 
EFLAGS CROSS-REFERENCE 


A.1 EFLAGS AND INSTRUCTIONS 


Table A-2 summarizes how the instructions affect the flags in the EFLAGS register. The following codes describe 
how the flags are affected. 


Table A-1. Codes Describing Flags 


Instruction tests flag. 


T 
M Instruction modifies flag (either sets or resets depending on operands). 
0 Instruction resets flag. 

1 Instruction sets flag. 

— Instruction’s effect on flag is undefined. 


R Instruction restores prior value of flag. 


Blank Instruction does not affect flag. 


Table A-2. EFLAGS Cross-Reference 

Instruction OF SF ZF AF PF CF TF IF DF NT RF 
AAA _ _ — T™ _ M 
AAD — 
AAM _ 
AAS _ — _ T™ _ M 
ADC M M M M M ™ 
ADD M M M M M 
0 M M M 

M 


AND 
ARPL 
BOUND 
BSF/BSR a — M a a a 
BSWAP 
BT/BTS/BTR/BTC = = = = M 
CALL 
CBW 
CLC 0 
CLD 0 
CLI 0 
CLTS 
CMC 
CMOVcc T T T T T 
CMP M M M M 
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Table A-2. EFLAGS Cross-Reference (Contd.) 


Instruction 


OF 


SF 


ZF 


AF 


PF 


CF 


TF 


DF 


NT 


RF 


CMPS 


M 


M 


M 


CMPXCHG 


M 


M 


M 


CMPXCHG8B 


COMISD 


COMISS 


Z\/3/48/8/58 


x 


CPUID 


CwD 


DAA 


x 


x 


™ 


x 


™ 


DAS 


x 


x 


™ 


x 


™ 


DEC 


x 


x 


x 


DIV 


ENTER 


ESC 


FCMOVcc 


FCOMI, FCOMIP, FUCOMI, FUCOMIP 


HLT 


IDIV 


IMUL 


INT 


INTO 


INVD 


INVLPG 


UCOMISD 


UCOMISS 


IRET 


Jcc 


o4|w)o|;o 


4) wvm;o/;o 


4H) vA\|s\|s 


4/ | s\/5 


4H, vA\|s\/s 


JCXzZ 


|MP 


LAHF 


LAR 


LDS/LES/LSS/LFS/LGS 


LEA 


LEAVE 


LGDT/LIDT/LLDT/LMSW 


LOCK 
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EFLAGS CROSS-REFERENCE 


Instruction 


OF 


SF 


ZF 


AF 


PF 


CF 


TF 


DF NT RF 


LODS 


LOOP 


LOOPE/LOOPNE 


LSL 


LTR 


MONITOR 


MWAIT 


MOV 


MOV control, debug, test 


MOVS 


MOVSX/MOVZX 


MUL 


NEG 


NOP 


NOT 


OR 


OUT 


OUTS 


POP/POPA 


POPF 


PUSH/PUSHA/PUSHF 


RCL/RCR 1 


™ 


RCL/RCR count 


™ 


RDMSR 


RDPMC 


RDTSC 


REP/REPE/REPNE 


RET 


ROL/ROR 1 


ROL/ROR count 


RSM 


SAHF 


SAL/SAR/SHL/SHR 1 


SAL/SAR/SHL/SHR count 


Z| S3\/a\ 3/5/53 


SBB 


SCAS 


SETcc 


4\/3/ 


a4\/S/S/3/85/D/8 


a\/Ss/s|\/3/8\/a/\8 


Aa\/S/S/8/8/0/8 


SGDT/SIDT/SLDT/SMSW 
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Table A-2. EFLAGS Cross-Reference (Contd.) 


Instruction 


OF 


SF 


ZF 


AF 


PF 


CF 


TF 


DF 


NT 


RF 


SHLD/SHRD 


M 


M 


M 


STC 


STD 


STI 


STOS 


STR 


SUB 


TEST 


UD 


VERR/VERRW 


WAIT 


WBINVD 


WRMSR 


XADD 


XCHG 


XLAT 


XOR 
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EFLAGS CONDITION CODES 


B.1 CONDITION CODES 

Table B-1 lists condition codes that can be queried using CMOVcc, FCMOVcc, Jcc, and SETcc. Condition codes refer 
to the setting of one or more status flags (CF, OF, SF, ZF, and PF) in the EFLAGS register. In the table below: 

¢ The “Mnemonic” column provides the suffix (cc) added to the instruction to specify a test condition. 

* “Condition Tested For” describes the targeted condition. 

¢ “Instruction Subcode” provides the opcode suffix added to the main opcode to specify the test condition. 

¢ “Status Flags Setting” describes the flag setting. 


Table B-1. EFLAGS Condition Codes 


Instruction 
Mnemonic (cc) Condition Tested For Subcode Status Flags Setting 
) Overflow 0000 OF =1 
NO No overflow 0001 OF =0 
B Below 0010 CF=1 
NAE Neither above nor equal 
NB Not below 0011 CF=0 
AE Above or equal 
E Equal 0100 ZF=1 
Z Zero 
NE Not equal 0101 ZF=0 
NZ Not zero 
BE Below or equal 0110 (CF OR ZF) = 1 
NA Not above 
NBE Neither below nor equal 0111 (CF OR ZF) = 0 
A Above 
S Sign 1000 SF =1 
NS No sign 1001 SF =0 
P Parity 1010 PF=1 
PE Parity even 
NP No parity 1011 PF=0 
PO Parity odd 
L Less 1100 (SF XOR OF) = 1 
NGE Neither greater nor equal 
NL Not less 1101 (SF XOR OF) = 0 
GE Greater or equal 
LE Less or equal 1110 ((SF XOR OF) OR ZF) = 1 
NG Not greater 
NLE Neither less nor equal 1111 ((SF XOR OF) OR ZF) = 0 
G Greater 


Many of the test conditions are described in two different ways. For example, LE (less or equal) and NG (not 
greater) describe the same test condition. Alternate mnemonics are provided to make code more intelligible. 
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The terms “above” and “below” are associated with the CF flag and refer to the relation between two unsigned 
integer values. The terms “greater” and “less” are associated with the SF and OF flags and refer to the relation 
between two signed integer values. 
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APPENDIX C 
FLOATING-POINT EXCEPTIONS SUMMARY 


C.1 OVERVIEW 


This appendix shows which of the floating-point exceptions can be generated for: 
°® x87 FPU instructions — see Table C-2 

¢ SSE instruction — see Table C-3 

¢ SSE2 instructions — see Table C-4 

¢ SSE3 instructions — see Table C-5 

° SSE4 instructions — see Table C-6 


Table C-1 lists types of floating-point exceptions that potentially can be generated by the x87 FPU and by 
SSE/SSE2/SSE3 instructions. 


Table C-1. x87 FPU and SIMD Floating-Point Exceptions 


Floating- 

point 

Exception Description 

#IS Invalid-operation exception for stack underflow or stack overflow (can only be generated for x87 FPU instructions)* 
#IA or #Il Invalid-operation exception for invalid arithmetic operands and unsupported formats* 
#D Denormal-operand exception 

#Z Divide-by-zero exception 

#0 Numeric-overflow exception 

#U Numeric-underflow exception 

#P Inexact-result (precision) exception 

NOTE: 


* The x87 FPU instruction set generates two types of invalid-operation exceptions: #IS (stack underflow or stack overflow) and #IA 
(invalid arithmetic operation due to invalid arithmetic operands or unsupported formats). SSE/SSE2/SSE3 instructions potentially 
generate #1 (invalid operation exceptions due to invalid arithmetic operands or unsupported formats). 


The floating point exceptions shown in Table C-1 (except for #D and #I1S) are defined in IEEE Standard 754-1985 
for Binary Floating-Point Arithmetic. See Section 4.9.1, “Floating-Point Exception Conditions,” for a detailed discus- 
sion of floating-point exceptions. 


C.2 X87 FPU INSTRUCTIONS 


Table C-2 lists the x87 FPU instructions in alphabetical order. For each instruction, it summarizes the floating-point 
exceptions that the instruction can generate. 


Table C-2. Exceptions Generated with x87 FPU Floating-Point Instructions 


Mnemonic Instruction #IS | #IA | #D | #Z | #0 | HU | #P 
F2XM1 Exponential Y Y Y Y Y 
FABS Absolute value Y 
FADD(P) Add floating-point Y;| Y/Y Y) YY 
FBLD BCD load Y 
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Table C-2. Exceptions Generated with x87 FPU Floating-Point Instructions (Contd.) 


C-2 Vol.1 


Mnemonic Instruction #IS | #IA | #D | #Z | #0 | HU | #P 
FBSTP BCD store and pop Y Y Y 
FCHS Change sign Y 
FCLEX Clear exceptions 
FCMOVcc Floating-point conditional move 
FCOM, FCOMP, FCOMPP Compare floating-point Y 
FCOMI, FCOMIP, FUCOMI, Compare floating-point and set EFLAGS Y 
FUCOMIP 
FCOS Cosine Y Y Y Y 
FDECSTP Decrement stack pointer 
FDIV(R)(P) Divide floating-point Y;)/Y]}Y¥]}Y¥]}Y]_Y]Y 
FFREE Free register 
FIADD Integer add Y Y Y Y Y Y 
FICOM(P) Integer compare Y Y Y 
FIDIV Integer divide Y Y Y Y 
FIDIVR Integer divide reversed Y Y Y Y Y 
FILD Integer load Y 
FIMUL Integer multiply Y Y Y Y Y Y 
FINCSTP Increment stack pointer 
FINIT Initialize processor 
FIST(P) Integer store Y 
FISTTP Truncate to integer Y 

(SSE3 instruction) 

FISUB(R) Integer subtract Y Y Y Y) YY 
FLD extended or stack Load floating-point Y 
FLD single or double Load floating-point Y Y Y 
FLD1 Load + 1.0 Y 
FLDCW Load Control word Y Y Y 4 
FLDENV Load environment Y ¥ Y ¥ 
FLDLZE Load logze Y 
FLDL2T Load logz10 Y 
FLDLG2 Load log; 92 Y 
FLDLN2 Load loge2 Y 
FLDPI Load x Y 
FLDZ Load + 0.0 MA 
FMUL(P) Multiply floating-point Y Y Y Y Y Y 
FNOP No operation 
FPATAN Partial arctangent Y Y Y 
FPREM Partial remainder Y 
FPREM1 IEEE partial remainder Y 


FLOATING-POINT EXCEPTIONS SUMMARY 


Table C-2. Exceptions Generated with x87 FPU Floating-Point Instructions (Contd.) 


Mnemonic Instruction #IS | #IA | #D | #Z | #0 | #U | #P 

FPTAN Partial tangent Y Y 
FRNDINT Round to integer Y 
FRSTOR Restore state Y Y Y;|Y}Y}Y4Y 
FSAVE Save state 
FSCALE Scale Y/ Y/Y Y Y 
FSIN Sine Y/Y]Y Y 
FSINCOS Sine and cosine Y Y Y Y 
FSQRT Square root Y Y Y Y 
FST(P) stack or extended | Store floating-point Y 
FST(P) single or double Store floating-point Y Y Y Y Y 
FSTCW Store control word 
FSTENV Store environment 
FSTSW (AX) Store status word 
FSUB(R)(P) Subtract floating-point Y Y|Y]Y 
FTST Test Y 
FUCOM(P)(P) Unordered compare floating-point Y 
FWAIT CPU Wait 
FXAM Examine 
FXCH Exchange registers Y 
FXTRACT Extract Y Y 
FYL2X Logarithm Y Y 
FYL2XP1 Logarithm epsilon Y Y 

Os SSE INSTRUCTIONS 

Table C-3 lists SSE instructions with at least one of the following characteristics: 

¢ have floating-point operands 

°* generate floating-point results 

¢ read or write floating-point status and control information 

The table also summarizes the floating-point exceptions that each instruction can generate. 

Table C-3. Exceptions Generated with SSE Instructions 
Mnemonic Instruction #1 | #D | #Z | #0 | #U | #P 

ADDPS Packed add. Y 
ADDSS Scalar add. Y 
ANDNPS Packed logical INVERT and AND. 
ANDPS Packed logical AND. 
CMPPS Packed compare. 
CMPSS Scalar compare. 
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Table C-3. Exceptions Generated with SSE Instructions (Contd.) 


Mnemonic Instruction #1 | #D | #Z | #0 | #U | #P 

COMISS Scalar ordered compare lower SP FP numbers and set the status Y Y 
flags. 

CVTPI2ZPS Convert two 32-bit signed integers from MM2/Mem to two SP FP. Y 

CVTPS2PI Convert lower two SP FP from XMM/Mem to two 32-bit signed Y 
integers in MM using rounding specified by MXCSR. 

CVTSI2SS Convert one 32-bit signed integer from Integer Reg/Mem to one Y 
SP FP. 

CVTSS2SI Convert one SP FP from XMM/Mem to one 32-bit signed integer Y Y 
using rounding mode specified by MXCSR, and move the result to 
an integer register. 

CVTTPS2PI Convert two SP FP from XMM2/Mem to two 32-bit signed Y Y 
integers in MM1 using truncate. 

CVTTSS2SI Convert lowest SP FP from XMM/Mem to one 32-bit signed Y Y 
integer using truncate, and move the result to an integer register. 

DIVPS Packed divide. 

DIVSS Scalar divide. Mi Y Y Y 

LDMXCSR Load control/status word. 

MAXPS Packed maximum. ¥ Y 

MAXSS Scalar maximum. Y Y 

MINPS Packed minimum. Y Y 

MINSS Scalar minimum. ¥ Y 

MOVAPS Move four packed SP values. 

MOVHLPS Move packed SP high to low. 

MOVHPS Move two packed SP values between memory and the high half of 
an XMM register. 

MOVLHPS Move packed SP low to high. 

MOVLPS Move two packed SP values between memory and the low half of 
an XMM register. 

MOVMSKPS Move sign mask to r32. 

MOVSS Move scalar SP number between an XMM register and memory or 
a second XMM register. 

MOVUPS Move unaligned packed data. 

MULPS Packed multiply. 

MULSS Scalar multiply. 

ORPS Packed OR. 

RCPPS Packed reciprocal. 

RCPSS Scalar reciprocal. 

RSQRTPS Packed reciprocal square root. 

RSQRTSS Scalar reciprocal square root. 

SHUFPS Shuffle. 

SQRTPS Square Root of the packed SP FP numbers. 

SQRTSS Scalar square root. 
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Table C-3. Exceptions Generated with SSE Instructions (Contd.) 


Mnemonic Instruction #1 | #D | #Z | #0 | #U | #P 
STMXCSR Store control/status word. 
SUBPS Packed subtract. 
SUBSS Scalar subtract. 
UCOMISS Unordered compare lower SP FP numbers and set the status flags. 
UNPCKHPS Interleave SP FP numbers. 
UNPCKLPS Interleave SP FP numbers. 
XORPS Packed XOR. 


C.4 SSE2 INSTRUCTIONS 


Table C-4 lists SSE2 instructions with at least one of the following characteristics: 


¢ floating-point operands 


¢ floating point results 


For each instruction, the table summarizes the floating-point exceptions that the instruction can generate. 


Table C-4. Exceptions Generated with SSE2 Instructions 


Instruction Description #1 | #D | #Z | #0 | HU | #P 
ADDPD Add two packed DP FP numbers from XMM2/Mem to XMM1. Y Y 
ADDSD Add the lower DP FP number from XMM2/Mem to XMM1. Y Y 
ANDNPD Invert the 128 bits in XMM1and then AND the result with 128 bits 
from XMM2/Mem. 
ANDPD Logical And of 128 bits from XMM2/Mem to XMM1 register. 
CMPPD Compare packed DP FP numbers from XMM2/Mem to packed DP Y Y 
FP numbers in XMM1 register using imm8 as predicate. 
CMPSD Compare lowest DP FP number from XMM2/Mem to lowest DP FP | Y Y 
number in XMM1 register using imm8 as predicate. 
COMISD Compare lower DP FP number in XMM1 register with lower DPFP | Y Y 
number in XMM2/Mem and set the status flags accordingly 
CVTDQ2PS Convert four 32-bit signed integers from XMM/Mem to four SP FP. 
CVTPS2DQ Convert four SP FP from XMM/Mem to four 32-bit signed integers | Y 
in XMM using rounding specified by MXCSR. 
CVTTPS2DQ Convert four SP FP from XMM/Mem to four 32-bit signed integers | Y Y 
in XMM using truncate. 
CVTDQ2PD Convert two 32-bit signed integers in XMM2/Mem to 2 DP FP in 
xmm1 using rounding specified by MXCSR. 
CVTPD2DQ Convert two DP FP from XMM2/Mem to two 32-bit signed Y Y 
integers in xmm1 using rounding specified by MXCSR. 
CVTPD2PI Convert lower two DP FP from XMM/Mem to two 32-bit signed Y Y 
integers in MM using rounding specified by MXCSR. 
CVTPD2PS Convert two DP FP to two SP FP. Y Y Y Y Y 
CVTPI2PD Convert two 32-bit signed integers from MM2/Mem to two DP FP. 
CVTPS2PD Convert two SP FP to two DP FP. Y Y 
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Table C-4. Exceptions Generated with SSE2 Instructions (Contd.) 


Instruction 


Description 


#l 


#D 


#Z 


#0 


#U 


#P 


CVTSD2SI 


Convert one DP FP from XMM/Mem to one 32 bit signed integer 
using rounding mode specified by MXCSR, and move the result to 
an integer register. 


Y 


CVTSD2SS 


Convert scalar DP FP to scalar SP FP. 


CVTSI2SD 


Convert one 32-bit signed integer from Integer Reg/Mem to one 
DP FP. 


CVTSS2SD 


Convert scalar SP FP to scalar DP FP. 


CVTTPD2DQ 


Convert two DP FP from XMM2/Mem to two 32-bit signed 
integers in XMM1 using truncate. 


CVTTPD2PI 


Convert two DP FP from XMM2/Mem to two 32-bit signed 
integers in MM1 using truncate. 


CVTTSD2SI 


Convert lowest DP FP from XMM/Mem to one 32 bit signed 
integer using truncate, and move the result to an integer register. 


DIVPD 


Divide packed DP FP numbers in XMM1 by XMM2/Mem 


DIVSD 


Divide lower DP FP numbers in XMM1 by XMM2/Mem 


MAXPD 


Return the maximum DP FP numbers between XMM2/Mem and 
XMM1. 


MAXSD 


Return the maximum DP FP number between the lower DP FP 
numbers from XMM2/Mem and XMM1. 


MINPD 


Return the minimum DP numbers between XMM2/Mem and 
XMM1. 


MINSD 


Return the minimum DP FP number between the lowest DP FP 
numbers from XMM2/Mem and XMM1. 


MOVAPD 


Move 128 bits representing 2 packed DP data from XMM2/Mem to 
XMM1 register. 


Or Move 128 bits representing 2 packed DP from XMM1 register 
to XMM2/Mem. 


MOVHPD 


Move 64 bits representing one DP operand from Mem to upper 
field of XMM register. 


Or move 64 bits representing one DP operand from upper field of 
XMM register to Mem. 


MOVLPD 


Move 64 bits representing one DP operand from Mem to lower 
field of XMM register. 


Or move 64 bits representing one DP operand from lower field of 
XMM register to Mem. 


MOVMSKPD 


Move the sign mask to r32. 


MOVSD 


Move 64 bits representing one scalar DP operand from 
XMM2/Mem to XMM1 register. 


Or move 64 bits representing one scalar DP operand from XMM1 
register to XMM2/Mem. 


MOVUPD 


Move 128 bits representing 2 DP data from XMM2/Mem to XMM1 
register. 


Or move 128 bits representing 2 DP data from XMM1 register to 
XMM2/Mem. 


MULPD 
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Multiply packed DP FP numbers in XMM2/Mem to XMM1. 


FLOATING-POINT EXCEPTIONS SUMMARY 


Table C-4. Exceptions Generated with SSE2 Instructions (Contd.) 


Instruction Description #1 | #D | #Z | #0 | HU | #P 
MULSD Multiply the lowest DP FP number in XMM2/Mem to XMM1. Y Y Y Y Y 
ORPD OR 128 bits from XMM2/Mem to XMM1 register. 
SHUFPD Shuffle Double. 
SQRTPD Square Root Packed Double-Precision Y Y Y 
SQRTSD Square Root Scaler Double-Precision Y Y Y 
SUBPD Subtract Packed Double-Precision. Y Y Y Y 
SUBSD Subtract Scaler Double-Precision. Y Y Y Y 
UCOMISD Compare lower DP FP number in XMM1 register with lower DPFP | Y Y 
number in XMM2/Mem and set the status flags accordingly. 
UNPCKHPD Interleaves DP FP numbers from the high halves of XMM1 and 
XMM2/Mem into XMM1 register. 
UNPCKLPD Interleaves DP FP numbers from the low halves of XMM1 and 
XMM2/Mem into XMM1 register. 
XORPD XOR 128 bits from XMM2/Mem to XMM1 register. 
C.5 SSE3 INSTRUCTIONS 
Table C-5 lists the SSE3 instructions that have at least one of the following characteristics: 
° have floating-point operands 
°* generate floating-point results 
For each instruction, the table summarizes the floating-point exceptions that the instruction can generate. 
Table C-5. Exceptions Generated with SSE3 Instructions 
Instruction Description #1 | #D | #Z | #0 | #U | #P 
ADDSUBPD Add /Sub packed DP FP numbers from XMM2/Mem to XMM1. Y Y Y Y Y 
ADDSUBPS Add /Sub packed SP FP numbers from XMM2/Mem to XMM1. Y Y Y Y Y 
FISTTP See Table C-2. Y Y 
HADDPD Add horizontally packed DP FP numbers XMM2/Mem to XMM1. Y Y Y Y Y 
HADDPS Add horizontally packed SP FP numbers XMM2/Mem to XMM1 Y Y Y Y Y 
HSUBPD Sub horizontally packed DP FP numbers XMM2/Mem to XMM1 Y Y Y Y Y 
HSUBPS Sub horizontally packed SP FP numbers XMM2/Mem to XMM1 Y Y Y Y Y 


Other SSE3 instructions do not generate floating-point exceptions. 


C.6 


C.7 


SSSE3 INSTRUCTIONS 


SSSE3 instructions operate on integer data elements. They do not generate floating-point exceptions. 


SSE4 INSTRUCTIONS 


Table C-6 lists the SSE4.1 instructions that generate floating-point results. 


For each instruction, the table summarizes the floating-point exceptions that the instruction can generate. 
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Table C-6. Exceptions Generated with SSE4 Instructions 


Instruction Description #1 |) 4D | #Z | #0 | HU | #P 
DPPD DP FP dot product. Y Y Y Y Y 
DPPS SP FP dot product. Y Y Y Y Y 
ROUNDPD Round packed DP FP values to integer FP values. Y yl 
ROUNDPS Round packed SP FP values to integer FP values. Y yl 
ROUNDSD Round scalar DP FP value to integer FP value. Y yl 
ROUNDSS Round scalar SP FP value to integer FP value. Y yl 
NOTES: 


1. If bit 3 of immediate operand is 0 


Other SSE4.1 instructions and SSE4.2 instructions do not generate floating-point exceptions. 


C-8 Vol. 1 


APPENDIX D 
GUIDELINES FOR WRITING SIMD FLOATING-POINT EXCEPTION 
HANDLERS 


See Section 11.5, “SSE, SSE2, and SSE3 Exceptions,” for a detailed discussion of SIMD floating-point exceptions. 


This appendix considers only SSE/SSE2/SSE3 instructions that can generate numeric (SIMD floating-point) excep- 
tions, and gives an overview of the necessary support for handling such exceptions. This appendix does not 
address instructions that do not generate floating-point exceptions (such as RSQRTSS, RSQRTPS, RCPSS, or 
RCPPS), any x87 instructions, or any unlisted instruction. 


For detailed information on which instructions generate numeric exceptions, and a listing of those exceptions, refer 
to Appendix C, “Floating-Point Exceptions Summary.” Non-numeric exceptions are handled in a way similar to that 
for the standard IA-32 instructions. 


D.1 TWO OPTIONS FOR HANDLING FLOATING-POINT EXCEPTIONS 


Just as for x87 FPU floating-point exceptions, the processor takes one of two possible courses of action when an 
SSE/SSE2/SSE3 instruction raises a floating-point exception: 


° If the exception being raised is masked (by setting the corresponding mask bit in the MXCSR to 1), thena 
default result is produced which is acceptable in most situations. No external indication of the exception is 
given, but the corresponding exception flags in the MXCSR are set and may be examined later. Note though 
that for packed operations, an exception flag that is set in the MXCSR will not tell which of the sub-operands 
caused the event to occur. 


¢ If the exception being raised is not masked (by setting the corresponding mask bit in the MXCSR to 0), a 
software exception handler previously registered by the user with operating system support will be invoked 
through the SIMD floating-point exception (#XM, exception 19). This case is discussed below in Section D.2, 
“Software Exception Handling.” 


D.2 SOFTWARE EXCEPTION HANDLING 


The #XM handler is usually part of the system software (the operating system kernel). Note that an interrupt 
descriptor table (IDT) entry must have been previously set up for exception 19 (refer to Chapter 6, “Interrupt and 
Exception Handling,” in the Inte/® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A). Some 
compilers use specific run-time libraries to assist in floating-point exception handling. If any x87 FPU floating-point 
operations are going to be performed that might raise floating-point exceptions, then the exception handling 
routine must either disable all floating-point exceptions (for example, loading a local control word with FLDCW), or 
it must be implemented as re-entrant. If this is not the case, the routine has to clear the status flags for x87 FPU 
exceptions or to mask all x87 FPU floating-point exceptions. For SIMD floating-point exceptions though, the excep- 
tion flags in MXCSR do not have to be cleared, even if they remain unmasked (but they may still be cleared). Excep- 
tions are in this case precise and occur immediately, and a SIMD floating-point exception status flag that is set 
when the corresponding exception is unmasked will not generate an exception. 


Typical actions performed by this low-level exception handling routine are: 
¢ Incrementing an exception counter for later display or printing 
¢ Printing or displaying diagnostic information (e.g. the MXCSR and XMM registers) 


¢ Aborting further execution, or using the exception pointers to build an instruction that will run without 
exception and executing it 


° Storing information about the exception in a data structure that will be passed to a higher level user exception 
handler 


In most cases (and this applies also to SSE/SSE2/SSE3 instructions), there will be three main components of a low- 
level floating-point exception handler: a prologue, a body, and an epilogue. 
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The prologue performs functions that must be protected from possible interruption by higher-priority sources - 
typically saving registers and transferring diagnostic information from the processor to memory. When the critical 
processing has been completed, the prologue may re-enable interrupts to allow higher-priority interrupt handlers 
to preempt the exception handler (assuming that the interrupt handler was called through an interrupt gate, 
meaning that the processor cleared the interrupt enable (IF) flag in the EFLAGS register - refer to Section 6.5.1, 
“Call and Return Operation for Interrupt or Exception Handling Procedures”). 


The body of the exception handler examines the diagnostic information and makes a response that is application- 
dependent. It may range from halting execution, to displaying a message, to attempting to fix the problem and 
then proceeding with normal execution, to setting up a data structure, calling a higher-level user exception handler 
and continuing execution upon return from it. This latter case will be assumed in Section D.4, “SIMD Floating-Point 
Exceptions and the IEEE Standard 754” below. 


Finally, the epilogue essentially reverses the actions of the prologue, restoring the processor state so that normal 
execution can be resumed. 


The following example represents a typical exception handler. To link it with Example D-2 that will follow in Section 
D.4.3, “Example SIMD Floating-Point Emulation Implementation,” assume that the body of the handler (not shown 
here in detail) passes the saved state to a routine that will examine in turn all the sub-operands of the excepting 
instruction, invoking a user floating-point exception handler if a particular set of sub-operands raises an unmasked 
(enabled) exception, or emulating the instruction otherwise. 


Example D-1. SIMD Floating-Point Exception Handler 
SIMD_FP_EXC_HANDLER PROC 


;PROLOGUE 
SAVE REGISTERS THAT MIGHT BE USED BY THE EXCEPTION HANDLER 
PUSH EBP SAVE EBP 
PUSH EAX SAVE EAX 
MOV EBP, ESP SAVE ESP in EBP 
SUB ESP, 512 ;ALLOCATE 512 BYTES 
AND ESP, OfffffffOh *MAKE THE ADDRESS 16-BYTE ALIGNED 
FXSAVE [ESP] SAVE FP, MMX, AND SIMD FP STATE 
PUSH [EBP+EFLAGS_OFFSET] ;COPY OLD EFLAGS TO STACK TOP 
POPFD ;RESTORE THE INTERRUPT ENABLE FLAG IF 
‘TO VALUE BEFORE SIMD FP EXCEPTION 
;BODY 
;APPLICATION-DEPENDENT EXCEPTION HANDLING CODE GOES HERE 
LDMXCSR LOCAL_MXCSR ;LOAD LOCAL MXCSR VALUE IF NEEDED 
;EPILOGUE 
FXRSTOR [ESP] ;RESTORE MODIFIED STATE IMAGE 
MOV ESP, EBP ;DE-ALLOCATE STACK SPACE 
POP EAX ;RESTORE EAX 
POP EBP ;RESTORE EBP 
IRET ‘RETURN TO INTERRUPTED CALCULATION 


SIMD_FP_EXC_HANDLER ENDP 
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D.3 EXCEPTION SYNCHRONIZATION 


An SSE/SSE2/SSE3 instruction can execute in parallel with other similar instructions, with integer instructions, and 
with floating-point or MMX instructions. Unlike for x87 instructions, special precaution for exception synchroniza- 
tion is not necessary in this case. This is because floating-point exceptions for SSE/SSE2/SSE3 instructions occur 
immediately and are not delayed until a subsequent floating-point instruction is executed. However, floating- 
point emulation may be necessary when unmasked floating-point exceptions are generated. 


D.4 SIMD FLOATING-POINT EXCEPTIONS AND THE IEEE STANDARD 754 


SSE/SSE2/SSE3 extensions are 100% compatible with the IEEE Standard 754 for Binary Floating-Point Arithmetic, 
satisfying all of its mandatory requirements (when the flush-to-zero or denormals-are-zeros modes are not 
enabled). But a programming environment that includes SSE/SSE2/SSE3 instructions will comply with both the 
obligatory and the strongly recommended requirements of the IEEE Standard 754 regarding floating-point excep- 
tion handling, only as a combination of hardware and software (which is acceptable). The standard states that a 
user should be able to request a trap on any of the five floating-point exceptions (note that the denormal exception 
is an IA-32 addition), and it also specifies the values (operands or result) to be delivered to the exception handler. 


The main issue is that for SSE/SSE2/SSE3 instructions that raise post-computation exceptions (traps: overflow, 
underflow, or inexact), unlike for x87 FPU instructions, the processor does not provide the result recommended by 
IEEE Standard 754 to the user handler. If a user program needs the result of an instruction that generated a post- 
computation exception, it is the responsibility of the software to produce this result by emulating the faulting 
SSE/SSE2/SSE3 instruction. Another issue is that the standard does not specify explicitly how to handle multiple 
floating-point exceptions that occur simultaneously. For packed operations, a logical OR of the flags that would be 
set by each sub-operation is used to set the exception flags in the MXCSR. The following subsections present one 
possible way to solve these problems. 


D.4.1 Floating-Point Emulation 


Every operating system must provide a kernel level floating-point exception handler (a template was presented in 
Section D.2, “Software Exception Handling” above). In the following discussion, assume that a user mode floating- 
point exception filter is supplied for SIMD floating-point exceptions (for example as part of a library of C functions), 
that a user program can invoke in order to handle unmasked exceptions. The user mode floating-point exception 
filter (not shown here) has to be able to emulate the subset of SSE/SSE2/SSE3 instructions that can generate 
numeric exceptions, and has to be able to invoke a user provided floating-point exception handler for floating-point 
exceptions. When a floating-point exception that is not masked is raised by an SSE/SSE2/SSE3 instruction, the 
low-level floating-point exception handler will be called. This low-level handler may in turn call the user mode 
floating-point exception filter. The filter function receives the original operands of the excepting instruction as no 
results are provided by the hardware, whether a pre-computation or a post-computation exception has occurred. 
The filter will unpack the operands into up to four sets of sub-operands, and will submit them one set at a time to 
an emulation function (See Example D-2 in Section D.4.3, “Example SIMD Floating-Point Emulation Implementa- 
tion”). The emulation function will examine the sub-operands, and will possibly redo the necessary calculation. 


Two cases are possible: 


¢ If an unmasked (enabled) exception would occur in this process, the emulation function will return to its caller 
(the filter function) with the appropriate information. The filter will invoke a (previously registered) user 
floating-point exception handler for this set of sub-operands, and will record the result upon return from the 
user handler (provided the user handler allows continuation of the execution). 


¢ If no unmasked (enabled) exception would occur, the emulation function will determine and will return to its 
caller the result of the operation for the current set of sub-operands (it has to be IEEE Standard 754 
compliant). The filter function will record the result (plus any new flag settings). 


The user level filter function will then call the emulation function for the next set of sub-operands (if any). When 
done with all the operand sets, the partial results will be packed (if the excepting instruction has a packed floating- 
point result, which is true for most SSE/SSE2/SSE3 numeric instructions) and the filter will return to the low-level 
exception handler, which in turn will return from the interruption, allowing execution to continue. Note that the 
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instruction pointer (EIP) has to be altered to point to the instruction following the excepting instruction, in order to 
continue execution correctly. 


If a user mode floating-point exception filter is not provided, then all the work for decoding the excepting instruc- 
tion, reading its operands, emulating the instruction for the components of the result that do not correspond to 
unmasked floating-point exceptions, and providing the compounded result will have to be performed by the user- 
provided floating-point exception handler. 


Actual emulation might have to take place for one operand or pair of operands for scalar operations, and for all sub- 
operands or pairs of sub-operands for packed operations. The steps to perform are the following: 


¢ The excepting instruction has to be decoded and the operands have to be read from the saved context. 


¢ The instruction has to be emulated for each (pair of) sub-operand(s); if no floating-point exception occurs, the 
partial result has to be saved; if a masked floating-point exception occurs, the masked result has to be 
produced through emulation and saved, and the appropriate status flags have to be set; if an unmasked 
floating-point exception occurs, the result has to be generated by the user provided floating-point exception 
handler, and the appropriate status flags have to be set. 


¢ The partial results have to be combined and written to the context that will be restored upon application 
program resumption. 


A diagram of the control flow in handling an unmasked floating-point exception is presented below. 


User Application 


Low-Level Floating-Point Exception Handler 


User Level Floating-Point Exception Filter 


User Floating-Point Exception Handler 


Figure D-1. Control Flow for Handling Unmasked Floating-Point Exceptions 


From the user-level floating-point filter, Example D-2 in Section D.4.3, “Example SIMD Floating-Point Emulation 
Implementation,” will present only the floating-point emulation part. In order to understand the actions involved, 
the expected response to exceptions has to be known for all SSE/SSE2/SSE3 numeric instructions in two situa- 
tions: with exceptions enabled (unmasked result), and with exceptions disabled (masked result). The latter can be 
found in Section 6.5, “Interrupts and Exceptions.” The response to NaN operands that do not raise an exception is 
specified in Section 4.8.3.4, “NaNs.” Operations on NaNs are explained in the same source. This response is also 
discussed in more detail in the next subsection, along with the unmasked and masked responses to floating-point 
exceptions. 


D.4.2 SSE/SSE2/SSE3 Response To Floating-Point Exceptions 


This subsection specifies the unmasked response expected from the SSE/SSE2/SSE3 instructions that raise 
floating-point exceptions. The masked response is given in parallel, as it is necessary in the emulation process of 
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the instructions that raise unmasked floating-point exceptions. The response to NaN operands is also included in 
more detail than in Section 4.8.3.4, “NaNs.” For floating-point exception priority, refer to “Priority Among Simulta- 
neous Exceptions and Interrupts” in Chapter 6, “Interrupt and Exception Handling,” of Intel® 64 and IA-32 Archi- 
tectures Software Developer’s Manual, Volume 3A. 


D.4.2.1 Numeric Exceptions 


There are six classes of numeric (floating-point) exception conditions that can occur: Invalid operation (#1), 
Divide-by-Zero (#Z), Denormal Operand (#D), Numeric Overflow (#0), Numeric Underflow (#U), and Inexact 
Result (precision) (#P). #1, #Z, #D are pre-computation exceptions (floating-point faults), detected before the 
arithmetic operation. #0, #U, #P are post-computation exceptions (floating-point traps). 


Users can control how the SSE/SSE2/SSE3 floating-point exceptions are handled by setting the mask/unmask bits 
in MXCSR. Masked exceptions are handled by the processor, or by software if they are combined with unmasked 
exceptions occurring in the same instruction. Unmasked exceptions are usually handled by the low-level exception 
handler, in conjunction with user-level software. 


D.4.2.2 Results of Operations with NaN Operands or a NaN Result for SSE/SSE2/SSE3 Numeric 
Instructions 


The tables below (E-1 through E-10) specify the response of SSE/SSE2/SSE3 instructions to NaN inputs, or to 
other inputs that lead to NaN results. 


These results will be referenced by subsequent tables (e.g., E-10). Most operations do not raise an invalid excep- 
tion for quiet NaN operands, but even so, they will have higher precedence over raising floating-point exceptions 
other than invalid operation. 


Note that the single precision QNaN Indefinite value is FFCOOOOOH, the double precision QNaN Indefinite value is 
FFF8000000000000H, and the Integer Indefinite value is 80000000H (not a floating-point number, but it can be 
the result of a conversion instruction from floating-point to integer). 


For an unmasked exception, no result will be provided by the hardware to the user handler. If a user registered 
floating-point exception handler is invoked, it may provide a result for the excepting instruction, that will be used 
if execution of the application code is continued after returning from the interruption. 


In Tables D-1 through Table D-12, the specified operands cause an invalid exception, unless the unmasked result 
is marked with “not an exception”. In this latter case, the unmasked and masked results are the same. 


Table D-1. ADDPS, ADDSS, SUBPS, SUBSS, MULPS, MULSS, DIVPS, DIVSS, ADDPD, ADDSD, SUBPD, SUBSD, MULPD, 
MULSD, DIVPD, DIVSD, ADDSUBPS, ADDSUBPD, HADDPS, HADDPD, HSUBPS, HSUBPD 


Source Operands Masked Result Unmasked Result 
SNaN1 op! SNaN2 SNaN1 | OO400000H or None 

SNaN1 | OOO8000000000000H2 
SNaN1 op QNaN2 SNaN1 | OO400000H or None 

SNaN1 | OOO8000000000000H2 
QNaN1 op SNaN2 QNaN1 None 
QNaN1 op QNaN2 QNaN1 QNaN1 (not an exception) 
SNaN op real value SNaN | OO400000H or None 

SNaN1 | OOO8000000000000H2 
Real value op SNaN SNaN | OO400000H or None 

SNaN1 | OOO8000000000000H2 
QNaN op real value QNaN QNaN (not an exception) 
Real value op QNaN QNaN QNaN (not an exception) 
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Table D-1. ADDPS, ADDSS, SUBPS, SUBSS, MULPS, MULSS, DIVPS, DIVSS, ADDPD, ADDSD, SUBPD, SUBSD, MULPD, 
MULSD, DIVPD, DIVSD, ADDSUBPS, ADDSUBPD, HADDPS, HADDPD, HSUBPS, HSUBPD (Contd.) 


Source Operands 


Masked Result 


Unmasked Result 


Neither source operand is SNaN, 
but #1 is signaled (e.g. for Inf - Inf, 
Inf * 0, Inf / Inf, 0/0) 


Single precision or double precision QNaN 
Indefinite 


None 


NOTES: 


1. For Tables E-1 to E-12: op denotes the operation to be performed. 


2. SNaN | OO400000H is a quiet NaN in single precision format (if SNaN is in single precision) and SNaN | OOOBOOOOOO0OO0ONNH is a 
quiet NaN in double precision format (if SNaN is in double precision), obtained from the signaling NaN given as input. 


3. Operations involving only quiet NaNs do not raise floating-point exceptions. 


Table D-2. CMPPS.EQ, CMPSS.EQ, CMPPS.ORD, CMPSS.ORD, 


CMPPD.EQ, CMPSD.EQ, CMPPD.ORD, CMPSD.ORD 


Source Operands 


Masked Result 


Unmasked Result 


NaN op Opd2 (any Opd2) 


OOOOO00O0OH or 0000000000000000H' 


O0000000H or 0000000000000000H' 
(not an exception) 


Opd1 op NaN (any Opd1) 


OOO00000H or 0O00000000000000H' 


QO0000000H or 0000000000000000H' 
(not an exception) 


NOTE: 


1. 32-bit results are for single, and 64-bit results for double precision operations. 


Table D-3. CMPPS.NEQ, CMPSS.NEQ, CMPPS.UNORD, CMPSS.UNORD, CMPPD.NEQ, CMPSD.NEQ, 


CMPPD.UNORD, CMPSD.UNORD 


Source Operands 


Masked Result 


Unmasked Result 


NaN op Opd2 (any Opd2) 


Opd1 op NaN (any Opd1) 


FFFFFFFFH or FRFFFFFFFFFFFFFFH! 


FFFFFFFFH or FRFFFFFFFFFEFFFFH" 


FFFFFFFFH or FFFFFFFFFFFFFFFFH! (not 
an exception) 


FFFFFFFFH or FEFFFFFFFFFFFFFFH | (not 
an exception) 


NOTE: 


1. 32-bit results are for single, and 64-bit results for double precision operations. 


Table D-4. CMPPS.LT, CMPSS.LT, CMPPS.LE, CMPSS.LE, CMPPD.LT, CMPSD.LT, CMPPD.LE, CMPSD.LE 


Source Operands 


Masked Result 


Unmasked Result 


NaN op Opd2 (any Opd2) 


O0000000H or OOODD00000000000H' 


None 


Opd1 op NaN (any Opd1) 
NOTE: 


O0000000H or 0OODD00000000000H' 


1. 32-bit results are for single, and 64-bit results for double precision operations. 
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Table D-5. CMPPS.NLT, CMPSS.NLT, CMPPS.NLE, CMPSS.NLE, CMPPD.NLT, CMPSD.NLT, CMPPD.NLE, CMPSD.NLE 


Source Operands 


Masked Result 


Unmasked Result 


NaN op Opd2 (any Opd2) 


FFFFFFFFH or FEFFFFFFFFFFFFFFH! 


None 


Opd1 op NaN (any Opd1) 


FFFFFFFFH or FFFFFFFFFFFFFFFFH" 


None 


NOTE: 


1. 32-bit results are for single, and 64-bit results for double precision operations. 


Table D-6. COMISS, COMISD 


Source Operands 


Masked Result 


Unmasked Result 


SNaN op Opde (any Opd2) OF, SF, AF = 000 None 
ZF, PF, CF =111 

Opd1 op SNaN (any Opd1) OF, SF, AF = 000 None 
ZF, PF, CF =111 

QNaN op Opde2 (any Opd2) OF, SF, AF = 000 None 
ZF, PF, CF =111 

Opd1 op QNaN (any Opd1) OF, SF, AF = 000 None 
ZF, PF, CF =111 


Table D-7. UCOMISS, UCOMISD 


Source Operands 


Masked Result 


Unmasked Result 


SNaN op Opde (any Opd2) OF, SF, AF = 000 None 
ZF, PF, CF = 111 
Opd1 op SNaN (any Opd1) OF, SF, AF = 000 None 
ZF, PF, CF = 111 
QNaN op Opd2 OF, SF, AF = 000 OF, SF, AF = 000 
(any Opd2 4 SNaN) ZF, PF, CF = 111 ZF, PF, CF = 111 (not an exception) 
Opd1 op QNaN OF, SF, AF = 000 OF, SF, AF = 000 
(any Opd1 # SNaN) ZF, PF, CF = 111 ZF, PF, CF = 111 (not an exception) 


Table D-8. CVTPS2PI, CVTSS2SI, CVTTPS2PI, CVTTSS2SI, CVTPD2PI, CVTSD2SI, CVTTPD2PI, CVTTSD2SI, 


CVTPS2DQ, CVTTPS2DQ, CVTPD2DQ, CVTTPD2DQ 


Source Operand Masked Result Unmasked Result 
SNaN 80000000H or 8000000000000000' None 
(Integer Indefinite) 
QNaN 80000000H or 8000000000000000' None 
(Integer Indefinite) 
NOTE: 


1. 32-bit results are for single, and 64-bit results for double precision operations. 
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Table D-9. MAXPS, MAXSS, MINPS, MINSS, MAXPD, MAXSD, MINPD, MINSD 


Source Operands Masked Result Unmasked Result 
Opd1 op NaN2 (any Opd1) NaN2 None 

NaN1 op Opd2 (any Opd2) Opd2 None 

NOTE: 


1. SNaN and QNaN operands raise an Invalid Operation fault. 


Table D-10. SQRTPS, SQRTSS, SQRTPD, SQRTSD 


Source Operand Masked Result Unmasked Result 
QNaN QNaN QNaN (not an exception) 
SNaN SNaN | OO400000H or None 
SNaN | OOO8000000000000H' 
Source operand is not SNaN; Single precision or None 
but #1 is signaled (e.g. for double precision QNaN Indefinite 
sqrt (-1.0)) 
NOTE: 


1. SNaN | OO400000H is a quiet NaN in single precision format (if SNaN is in single precision) and SNaN | OOOBOOOOOOOOOOOOH is a 
quiet NaN in double precision format (if SNaN is in double precision), obtained from the signaling NaN given as input. 


Table D-11. CVTPS2PD, CVTSS2SD 


Source Operands Masked Result Unmasked Result 

QNaN QNaN1! QNaN1! (not an exception) 
SNaN QNaN1¢ None 

NOTES: 


1. The double precision output QNaN1 is created from the single precision input QNaN as follows: the sign bit is preserved, the 8-bit 
exponent FFH is replaced by the 11-bit exponent 7FFH, and the 24-bit significand is extended to a 53-bit significand by appending 
29 bits equal to 0. 

2. The double precision output QNaN1 is created from the single precision input SNaN as follows: the sign bit is preserved, the 8-bit 
exponent FFH is replaced by the 11-bit exponent 7FFH, and the 24-bit significand is extended to a 53-bit significand by pending 
29 bits equal to 0. The second most significant bit of the significand is changed from O to 1 to convert the signaling NaN into a 
quiet NaN. 


Table D-12. CVTPD2PS, CVTSD2SS 


Source Operands Masked Result Unmasked Result 

QNaN QNaN1! QNaN1! (not an exception) 
SNaN QNaN1¢ None 

NOTES: 


1. The single precision output QNaN1 is created from the double precision input QNaN as follows: the sign bit is preserved, the 11-bit 
exponent 7FFH is replaced by the 8-bit exponent FFH, and the 53-bit significand is truncated to a 24-bit significand by removing its 
29 least significant bits. 

2. The single precision output QNaN1 is created from the double precision input SNaN as follows: the sign bit is preserved, the 11-bit 
exponent 7FFH is replaced by the 8-bit exponent FFH, and the 53-bit significand is truncated to a 24-bit significand by removing its 
29 least significant bits. The second most significant bit of the significand is changed from O to 1 to convert the signaling NaN into 
a quiet NaN. 
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D.4.2.3 Condition Codes, Exception Flags, and Response for Masked and Unmasked Numeric 
Exceptions 


In the following, the masked response is what the processor provides when a masked exception is raised by an 
SSE/SSE2/SSE3 numeric instruction. The same response is provided by the floating-point emulator for 
SSE/SSE2/SSE3 numeric instructions, when certain components of the quadruple input operands generate excep- 
tions that are masked (the emulator also generates the correct answer, as specified by IEEE Standard 754 wher- 
ever applicable, in the case when no floating-point exception occurs). The unmasked response is what the 
emulator provides to the user handler for those components of the packed operands of SSE/SSE2/SSE3 instruc- 
tions that raise unmasked exceptions. Note that for pre-computation exceptions (floating-point faults), no result is 
provided to the user handler. For post-computation exceptions (floating-point traps), a result is provided to the 
user handler, as specified below. 


In the following tables, the result is denoted by 'res', with the understanding that for the actual instruction, the 
destination coincides with the first source operand (except for COMISS, UCOMISS, COMISD, and UCOMISD, whose 
destination is the EFLAGS register). 


Table D-13. #1 - Invalid Operations 


Unmasked Response 

Instruction Condition Masked Response and Exception Code 
ADDPS srcl or src2! = SNaN Refer to Table D-1 for src1, src2 unchanged; #1A 
ADDPD NaN operands, #IA = 1 =1 
ADDSS 
ADDSD 
HADDPS 
HADDPD 
ADDSUBPS (the srcl = +Inf, src2 = -Inf or res! = QNaN Indefinite, 
addition component) | src1 = -Inf, src2 = +Inf #IA = 1 
ADDSUBPD (the 
addition component) 
SUBPS srcl or src2 = SNaN Refer to Table D-1 for NaN src1, src2 unchanged; #1A 
SUBPD operands, #IA = 1 =1 
SUBSS 
SUBSD 
HSUBPS 
HSUBPD 
ADDSUBPS (the srcl = +Inf, src2 = +Inf or res = QNaN Indefinite, 
subtraction src1 = -Inf, src2 = -Inf #IA=1 
component) 
ADDSUBPD (the 
subtraction 
component) 
MULPS srcl or src2 = SNaN Refer to Table D-1 for src1, src2 unchanged; 
MULPD NaN operands, #IA = 1 #IA = 1 
MULSS src = +Inf, src2 = +0 or res = QNaN Indefinite, 
MULSD srcl = +0, src2 = +Inf #IA = 1 
DIVPS srcl or src2 = SNaN Refer to Table D-1 for srcl, src2 unchanged; 
DIVPD NaN operands, #IA = 1 #IA = 1 
DIVSS src1 = +Inf, src2 = +Inf or res = QNaN Indefinite, 
DIVSD srcl = +0, src2 = +0 #IA = 1 
SQRTPS src = SNaN Refer to Table D-10 for src unchanged, 
SQRTPD NaN operands, #IA = 1 #IA = 1 
tues src < 0 res = QNaN Indefinite, 

(note that -0 < Ois false) #IA=1 
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Table D-13. #1- Invalid Operations (Contd.) 


Instruction 


Condition 


Masked Response 


Unmasked Response 
and Exception Code 


MAXPS 
MAXSS 
MAXPD 
MAXSD 


srcl = NaN or src2 = NaN 


res = src2, #IA = 1 


src1, src2 unchanged; #1A 
=1 


MINPS 
MINSS 
MINPD 
MINSD 


src1 = NaN or src2 = NaN 


res = src2, #IA = 1 


srcl, src2 unchanged; #1A 
=1 


CMPPS.LT 
CMPPS.LE 
CMPPS.NLT 
CMPPS.NLE 
CMPSS.LT 
CMPSS.LE 
CMPSS.NLT 
CMPSS.NLE 
CMPPD.LT 
CMPPD.LE 
CMPPD.NLT 
CMPPD.NLE 
CMPSD.LT 
CMPSD.LE 
CMPSD.NLT 
CMPSD.NLE 


src1 = NaN or src2 = NaN 


Refer to Table D-4 and Table D-5 for 
NaN operands; #1A = 1 


src1, src2 unchanged; #1A 
=1 


COMISS 
COMISD 


src1 = NaN or src2 = NaN 


Refer to Table D-6 for NaN 
operands 


src1, src2, EFLAGS 
unchanged; #IA = 1 


UCOMISS 
UCOMISD 


scl = SNaN or src2 = SNaN 


Refer to Table D-7 for NaN 
operands 


src1, src2, EFLAGS 
unchanged; #IA = 1 


CVTPS2PI 
CVTSS2SI 
CVTPD2PI 
CVTSD2SI 
CVTPS2DQ 
CVTPD2DQ 


src = NaN, +Inf, or 
\(STC) png | > 7FFFFFFFH and (src)-qq# 
80000000H 


See Note? for information 
on rnd. 


res = Integer Indefinite, 
#IA= 1 


src unchanged, 
#IA=1 


CVTTPS2PI 
CVTTSS2SI 
CVTTPD2PI 
CVTTSD2SI! 
CVTTPS2DQ 
CVTTPD2DQ 


src = NaN, +lnf, or 
\(stc),z | > 7FFFFFFFH and (src). # 
80000000H 


See Note? for information 
on rz. 


res = Integer Indefinite, 
#IA= 1 


src unchanged, 
#IA=1 
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Table D-13. #1 - Invalid Operations (Contd.) 


Unmasked Response 
Instruction Condition Masked Response and Exception Code 
CVTPS2PD src = SNAN Refer to Table D-11 for src unchanged, 
CVTSS2SD NaN operands #IA = 1 
CVTPD2PS src = SNAN Refer to Table D-12 for src unchanged, 
CVTSD2SS NaN operands #IA = 1 
NOTES: 


_- 


. For Tables E-13 to €-18: 
- src denotes the single source operand of a unary operation. 
- src1, src2 denote the first and second source operand of a binary operation. 
- res denotes the numerical result of an operation. 


2. rnd signifies the user rounding mode from MXCSR, and rz signifies the rounding mode toward Zero. (truncate), when rounding a 


floating-point value to an integer. For more information, refer to Table 4-8. 
. For NAN encodings, see Table 4-3. 


Ww 


Table D-14. #Z - Divide-by-Zero 


Unmasked Response 
Instruction Condition Masked Response and Exception Code 
DIVPS src1 = finite non-zero (normal, or res = +Inf, src1, src2 unchanged; 
DIVSS denormal) #ZE = 1 #ZE=1 
DIVPD src2 = +0 
DIVPS 
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Table D-15. #D - Denormal Operand 


Instruction 


Condition 


Masked Response 


Unmasked Response and 
Exception Code 


ADDPS 
ADDPD 
ADDSUBPS 
ADDSUBPD 
HADDPS 
HADDPD 
SUBPS 
SUBPD 
HSUBPS 
HSUBPD 
MULPS 
MULPD 
DIVPS 
DIVPD 
SOQRTPS 
SOQRTPD 
MAXPS 
MAXPD 
MINPS 
MINPD 
ADDSS 
ADDSD 
SUBSS 
SUBSD 
MULSS 
MULSD 
DIVSS 
DIVSD 
SOQRTSS 
SQRTSD 
MAXSS 
MAXSD 
MINSS 
MINSD 
CVTPS2PD 
CVTSS2SD 
CVTPD2PS 
CVTSD2SS 


CMPPS 
CMPPD 
CMPSS 
CMPSD 


src1 = denormal! or 
src2 = denormal (and 
the DAZ bit in MXCSR 
is O) 


srcl = denormal! or 
src2 = denormal (and 
the DAZ bit in MXCSR 
is 0) 


res = Result rounded to the 
destination precision and using the 
bounded exponent, but only if no 
unmasked post-computation 
exception occurs; 

#DE = 1. 


Comparison result, stored in the 
destination register; 
#DE = 1 


src1, src2 unchanged; 
#DE=1 


Note that SQRT, CVTPS2PD, 
CVTSS2SD, CVTPD2PS, CVTSD2SS 
have only 1 src. 


src1, src2 unchanged; 
#DE=1 


COMISS 
COMISD 
UCOMISS 
UCOMISD 


srcl = denormal! or 
src2 = denormal (and 
the DAZ bit in MXCSR 
is 0) 


Comparison result, stored in the 
EFLAGS register; 
#DE=1 


src1, src2 unchanged; 
#DE=1 


NOTE: 


1. For denormal encodings, see Section 4.8.3.2, “Normalized and Denormalized Finite Numbers.” 
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Table D-16. #0 - Numeric Overflow 


Unmasked Response and 


Instruction Condition Masked Response Exception Code 
ADDPS Rounded result > Rounding | Sign Result & Status Flags res = (result calculated with 
ADDSUBPS largest single To #OE=1.#PE=1 unbounded exponent and rounded 
HADDPS precision finite didarest é eee A to the destination precision) / 2192 
SUBPS normal value . a #0E = 1 
HSUBPS #PE = 1 if the result is inexact 
MULPS Toward —se #OE = 1, #PE=1 
DIVPS + | res= 1.11.1 *2!27 
ADDSS é res = —s° 
SUBSS Toward + HOE = 1, #PE=1 
MULSS 7 fas S08 
DIVSS -  |res=-1.11..1* 2127 
CVTPD2PS 
CVTSD2SS Toward #OE = 1, #PE=1 
0 + |res= i. * 22? 
-  |res=-1.11..1 * 2147 
ADDPD Rounded result > Rounding | Sign Result & Status Flags res = (result calculated with 
ADDSUBPD largest double To #OE=1.#PE=1 unbounded exponent and rounded 
HADDPD precision finite Abarast % ee - to the destination precision) / 2!°3° 
SUBPD normal value 7 a * #0€=1 _ 
HSUBPD = #PE = 1 if the result is inexact 
MULPD Toward —se #OE = 1, #PE=1 
DIVPD &  |pes= 117,21 #21083 
ADDSD i res = —s° 
SUBSD Toward + HOE = 1, #PE=1 
MULSD + ae Stes 
DIVSD - res =-1.11..1 * 21023 
Toward #0E = 1, #PE=1 
0 + \ves= til #203 


res = -1.11...1 * 21023 
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Table D-17. #U - Numeric Underflow 


D-14 Vol. 1 


Unmasked Response and 
Instruction Condition Masked Response Exception Code 
ADDPS Result calculated with unbounded res = +0, denormal, or normal res = (result calculated with 
ADDSUBPS exponent and rounded to the unbounded exponent and rounded 
HADDPS destination precision < smallest #UE = 1 and #PE = 1, to the destination precision) * 2! 
SUBPS single precision finite normal value. | but only if the result is = #UE=1 
HSUBPS inexact = #PE= 1 if the result is inexact 
MULPS 
DIVPS 
ADDSS 
SUBSS 
MULSS 
DIVSS 
CVTPD2PS 
CVTSD2SS 
ADDPD Result calculated with unbounded res = +0, denormal or normal res = (result calculated with 
ADDSUBPD exponent and rounded to the unbounded exponent and rounded 
HADDPD destination precision < smallest #UE = 1 and #PE = 1, to the destination precision) * 2'*7° 
SUBPD double precision finite normal value. | but only if the result is = #UE=1 
HSUBPD inexact = #PE = 1 if the result is inexact 
MULPD 
DIVPD 
ADDSD 
SUBSD 
MULSD 
DIVSD 
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Table D-18. #P - Inexact Result (Precision) 


Instruction Condition Masked Response Unmasked Response and Exception Code 


ADDPS The result is not exactly | res = Result rounded to the | Only if no underflow/overflow condition occurred, or 
ADDPD representable in the destination precision and if the corresponding exceptions are masked: 
ADDSUBPS destination format. using the bounded = Set #0€ if masked overflow and set result as 
ADDSUBPD exponent, but only if no described above for masked overflow. 

HADDPS unmasked underflow or * Set #UE if masked underflow and set result as 
HADDPD overflow conditions occur described above for masked underflow. 

SUBPS (this exception can occur in If neither underflow nor overflow, res equals the 
SUBPD the presence of a masked result rounded to the destination precision and using 


HSUBPS underflow or overflow); #Pe | the bounded exponent set #PE = 1. 
HSUBPD =1. 
MULPS 
MULPD 
DIVPS 
DIVPD 
SQRTPS 
SQRTPD 
CVTDQ2PS 
CVTPI2PS 
CVTPS2PI 
CVTPS2DQ 
CVTPD2PI 
CVTPD2DQ 
CVTPD2PS 
CVTTPS2PI 
CVTTPD2PI 
CVTTPD2DQ 
CVTTPS2DQ 
ADDSS 
ADDSD 
SUBSS 
SUBSD 
MULSS 
MULSD 
DIVSS 
DIVSD 
SQRTSS 
SQRTSD 
CVTSI2SS 
CVTSS2SI 
CVTSD2SI 
CVTSD2SS 
CVTTSS2SI 
CVTTSD2SI 


D.4.3 Example SIMD Floating-Point Emulation Implementation 


The sample code listed below may be considered as being part of a user-level floating-point exception filter for the 
SSE/SSE2/SSE3 numeric instructions. It is assumed that the filter function is invoked by a low-level exception 
handler (invoked for exception 19 when an unmasked floating-point exception occurs), and that it operates as 
explained in Section D.4.1, “Floating-Point Emulation.” The sample code does the emulation only for the SSE 
instructions for addition, subtraction, multiplication, and division. For this, it uses C code and x87 FPU operations. 
Operations corresponding to other SSE/SSE2/SSE3 numeric instructions can be emulated similarly. The example 
assumes that the emulation function receives a pointer to a data structure specifying a number of input parame- 
ters: the operation that caused the exception, a set of sub-operands (unpacked, of type float), the rounding mode 


Vol.1 D-15 


GUIDELINES FOR WRITING SIMD FLOATING-POINT EXCEPTION HANDLERS 


(the precision is always single), exception masks (having the same relative bit positions as in the MXCSR but 
starting from bit 0 in an unsigned integer), and flush-to-zero and denormals-are-zeros indicators. 


The output parameters are a floating-point result (of type float), the cause of the exception (identified by constants 
not explicitly defined below), and the exception status flags. The corresponding C definition is: 


typedef struct { 
unsigned int operation; //SSE or SSE2 operation: ADDPS, ADDSS, ... 
unsigned int operand1_uint32; //first operand value 
unsigned int operand2_uint32; //second operand value (if any) 
float result_fval; // result value (if any) 
unsigned int rounding_mode; //rounding mode 
unsigned int exc_masks; //exception masks, in the order P,U,O,Z,D,| 
unsigned int exception_cause; //exception cause 
unsigned int status_flag_inexact; //inexact status flag 
unsigned int status_flag_underflow; //underflow status flag 
unsigned int status_flag_overflow; //overflow status flag 
unsigned int status_flag_divide_by_zero; 


//divide by zero status flag 


unsigned int status_flag_denormal_operand; 


//denormal operand status flag 


unsigned int status_flag_invalid_operation; 


//invalid operation status flag 


unsigned int ftz; // flush-to-zero flag 
unsigned int daz; // denormals-are-zeros flag 
} EXC_ENV; 


The arithmetic operations exemplified are emulated as follows: 


1. 


If the denormals-are-zeros mode is enabled (the DAZ bit in MXCSR is set to 1), replace all the denormal inputs 
with zeroes of the same sign (the denormal flag is not affected by this change). 


Perform the operation using x87 FPU instructions, with exceptions disabled, the original user rounding mode, 
and single precision. This reveals invalid, denormal, or divide-by-zero exceptions (if there are any) and stores 
the result in memory as a double precision value (whose exponent range is large enough to look like 
“unbounded” to the result of the single precision computation). 


If no unmasked exceptions were detected, determine if the magnitude of the result is less than the smallest 
normal number that can be represented in single precision format, or greater than the largest normal number 
that can be represented in single precision format (huge). If an unmasked overflow or underflow occurs, 
calculate the scaled result that will be handed to the user exception handler, as specified by IEEE Standard 754. 


If no exception was raised, calculate the result with a “bounded” exponent. If the result is tiny, it requires 
denormalization (shifting the significand right while incrementing the exponent to bring it into the admissible 
range of [-126,+127] for single precision floating-point numbers). 


The result obtained in step 2 cannot be used because it might incur a double rounding error (it was rounded to 
24 bits in step 2, and might have to be rounded again in the denormalization process). To overcome this is, 
calculate the result as a double precision value, and store it to memory in single precision format. 


Rounding first to 53 bits in the significand, and then to 24 never causes a double rounding error (exact 
properties exist that state when double-rounding error occurs, but for the elementary arithmetic operations, 
the rule of thumb is that if an infinitely precise result is rounded to 2p+1 bits and then again to p bits, the result 
is the same as when rounding directly to p bits, which means that no double-rounding error occurs). 


If the result is inexact and the inexact exceptions are unmasked, the calculated result will be delivered to the 
user floating-point exception handler. 


The flush-to-zero case is dealt with if the result is tiny. 
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7. The emulation function returns RAISE_EXCEPTION to the filter function if an exception has to be raised (the 
exception_cause field indicates the cause). Otherwise, the emulation function returns DO_NOT_ 
RAISE_EXCEPTION. In the first case, the result is provided by the user exception handler called by the filter 
function. In the second case, it is provided by the emulation function. The filter function has to collect all the 
partial results, and to assemble the scalar or packed result that is used if execution is to continue. 


Example D-2. SIMD Floating-Point Emulation 


// masks for individual status word bits 
#define PRECISION MASK 20H 

#define UNDERFLOW MASK 10H 

#define OVERFLOW MASK 08H 

#define ZERODIVIDE MASK 04H 

#define DENORMAL MASK 02H 

#define INVALID MASK 01H 


// 32-bit constants 


static unsigned ZEROF ARRAY[] = {00000000H}; 
#define ZEROF *(float *) ZEROF ARRAY 

// +0.0 
static unsigned NZEROF ARRAY[] = {80000000H}; 
#define NZEROF *(float *) NZEROF_ ARRAY 

// -0.0 
static unsigned POSINFF_ARRAY[] = {7£800000H}; 
#define POSINFF *(float *)POSINFF ARRAY 

// +Inf 
static unsigned NEGINFF_ARRAY[] = {f££800000H}; 
#define NEGINFF * (float *)NEGINFF_ ARRAY 

// -Inf 


// 64-bit constants 
static unsigned MIN SINGLE NORMAL ARRAY [] = {00000000H, 38100000H}; 
#define MIN SINGLE NORMAL * (double *)MIN SINGLE NORMAL ARRAY 

// +1.0 * 2*-126 
static unsigned MAX SINGLE NORMAL ARRAY [] = {70000000H, 47efff£f£fH}; 
#define MAX SINGLE NORMAL * (double *)MAX SINGLE NORMAL ARRAY 

Ad. Pl McK AE2PK 197 
static unsigned TWO TO 192 ARRAY[] = {00000000H, 4b£00000H}; 
#define TWO TO 192 *(double *)TWO TO 192 ARRAY 

// +1.0 * 2%192 
static unsigned TWO_TO M192 ARRAY[] = {00000000H, 33£00000H}; 
#define TWO TO M192 *(double *)TWO TO M192 ARRAY 

// +1.0 * 2*-192 


// auxiliary functions 


static int isnanf (unsigned int ); // returns 1 if f is a NaN, and 0 otherwise 
static float quietf (unsigned int ); // converts a signaling NaN to a quiet 

// NaN, and leaves a quiet NaN unchanged 
static unsigned int check _for_daz (unsigned int ); // converts denormals 


// to zeros of the same sign; 
// does not affect any status flags 


// emulation of SSE and SSE2 instructions using 
// C code and x87 FPU instructions 


unsigned int 
simd_fp_emulate (EXC_ENV *exc_env) 


{ 


int uiopd1; // first operand of the add, subtract, multiply, or divide 

int uiopd2; // second operand of the add, subtract, multiply, or divide 

float res; // result of the add, subtract, multiply, or divide 

double dbl_res24; // result with 24-bit significand, but "unbounded" exponent 
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// (needed to check tininess, to provide a scaled result to 
// an underflow/overflow trap handler, and in flush-to-zero mode) 
double dbl_res; // result in double precision format (needed to avoid a 
// double rounding error when denormalizing) 
unsigned int result _tiny; 
unsigned int result_huge; 
unsigned short int sw; // 16 bits 
unsigned short int cw; // 16 bits 


// have to check first for faults (V, D, Z), and then for traps (0, U, I) 
// initialize x87 FPU (floating-point exceptions are masked) 


_asm { 
fninit; 


result_tiny 
result_huge 


oil 
oo 


switch (exc_env->operation) { 


case ADDPS: 
case ADDSS: 
case SUBPS: 
case SUBSS: 
case MULPS: 
case MULSS: 
case DIVPS: 
case DIVSS: 


uiopdl = exc_env->operandl_uint32; // copy as unsigned int 
// do not copy as float to avoid conversion 
// of SNaN to QNaN by compiled code 

uiopd2 = exc_env->operand2_uint32; 
// do not copy as float to avoid conversion of SNaN 
// to QNaN by compiled code 

uiopdl = check _for_daz (uiopd1); // operandl = +0.0 * operandi if it is 

// denormal and DAZ=1 


uiopd2 = check for daz (uiopd2); // operand2 = +0.0 * operand2 if it is 


// denormal and DAZ=1 


// execute the operation and check whether the invalid, denormal, or 
// divide by zero flags are set and the respective exceptions enabled 


// set control word with rounding mode set to exc_env->rounding_ mode, 
// single precision, and all exceptions disabled 
switch (exc_env->rounding_ mode) { 


case ROUND TO NEAREST: 
cw = 003fH; // round to nearest, single precision, exceptions masked 
break; 
case ROUND_DOWN: 
cw = 043fH; // round down, single precision, exceptions masked 
break; 
case ROUND_UP: 
cw = 083fH; // round up, single precision, exceptions masked 
break; 
case ROUND_TO_ZERO: 
cw = O0c3fH; // round to zero, single precision, exceptions masked 
break; 
default: 
} 
__asm { 


fldcw WORD PTR cw; 
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// compute result and round to the destination precision, with 
// "unbounded" exponent (first IEEE rounding) 
switch (exc_env->operation) { 


case ADDPS: 
case ADDSS: 
// perform the addition 


} 


asm { 

fnclex; 

// load input operands 

fld DWORD PTR uiopdi; // may set denormal or invalid status flags 
fld DWORD PTR uiopd2; // may set denormal or invalid status flags 
faddp st(1), st(0); // may set inexact or invalid status flags 

// store result 

fstp QWORD PTR dbl _res24; // exact 


break; 


case SUBPS: 
case SUBSS: 
// perform the subtraction 


} 


asm { 

fnclex; 

// load input operands 

fld DWORD PTR uiopdi1; // may set denormal or invalid status flags 
fld DWORD PTR uiopd2; // may set denormal or invalid status flags 
fsubp st(1), st(0); // may set the inexact or invalid status flags 


// store result 
fstp QWORD PTR dbl_res24; // exact 


break; 


case MULPS: 
case MULSS: 
// perform the multiplication 


} 


asm { 

fnclex; 

// load input operands 

fld DWORD PTR uiopdi; // may set denormal or invalid status flags 
fld DWORD PTR uiopd2; // may set denormal or invalid status flags 
fmulp st(1), st(0); // may set inexact or invalid status flags 


// store result 
fstp QWORD PTR dbl _res24; // exact 


break; 


case DIVPS: 
case DIVSS: 
// perform the division 


} 


asm { 
fnclex; 
// load input operands 
fld DWORD PTR uiopd1; // may set denormal or invalid status flags 
fld DWORD PTR uiopd2; // may set denormal or invalid status flags 
fdivp st(1), st(0); // may set the inexact, divide by zero, or 

// invalid status flags 


// store result 
fstp QWORD PTR dbl_res24; // exact 


break; 
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default: 
; // will never occur 


// vead status word 
__asm { 
fstsw WORD PTR sw; 


if (sw & ZERODIVIDE MASK) 
sw = sw & ~DENORMAL MASK; // clear D flag for (denormal / 0) 


// if invalid flag is set, and invalid exceptions are enabled, take trap 
if (!(exc_env->exc_masks & INVALID MASK) && (sw & INVALID MASK)) { 
exc_env->status_flag_invalid_operation = 1; 
exc_env->exception_cause = INVALID OPERATION; 
return (RAISE EXCEPTION) ; 


} 


// checking for NaN operands has priority over denormal exceptions; 
// also fix for the SSE and SSE2 

// differences in treating two NaN inputs between the 

// instructions and other IA-32 instructions 

if (isnanf (uiopd1) || isnanf (uiopd2)) { 


if (isnanf (uiopdl) && isnanf (uiopd2) ) 
exc_env->result_fval = quietf (uiopdl) ; 

else 
exc_env->result_fval = (float)dbl_res24; // exact 


if (sw & INVALID MASK) exc_env->status_flag_ invalid_operation = 1; 
return (DO NOT RAISE EXCEPTION) ; 


} 


// if denormal flag set, and denormal exceptions are enabled, take trap 
if (!(exc_env->exc_masks & DENORMAL MASK) && (sw & DENORMAL MASK)) { 
exc_env->status_flag_denormal_operand = 1; 
exc_env->exception_cause = DENORMAL OPERAND; 
return (RAISE EXCEPTION) ; 


} 


// if divide by zero flag set, and divide by zero exceptions are 

// enabled, take trap (for divide only) 

if (!(exc_env->exc_masks & ZERODIVIDE MASK) && (sw & ZERODIVIDE MASK)) { 
exc_env->status_ flag divide _by zero = 1; 
exc_env->exception_cause = DIVIDE BY ZERO; 
return (RAISE EXCEPTION) ; 


} 


// done if the result is a NaN (QNaN Indefinite) 

res = (float)dbl_res24; 

if (isnanf (*(unsigned int *)&res)) { 
exc_env->result_fval = res; // exact 
exc_env->status_flag_invalid_operation = 1; 
return (DO NOT RAISE EXCEPTION) ; 


} 


// dbl_res24 is not a NaN at this point 
if (sw & DENORMAL MASK) exc_env->status_flag_denormal_operand = 1; 
// Note: (dbl_res24 == 0.0 && sw & PRECISION MASK) cannot occur 


if (-MIN_SINGLE NORMAL < dbl_res24 && dbl_res24 < 0.0 || 
0.0 < dbl_res24 && dbl_res24 < MIN SINGLE NORMAL) { 
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result_tiny = 1; 


} 


// check if the result is huge 
if (NEGINFF < dbl_res24 && dbl_res24 < -MAX SINGLE NORMAL | | 
MAX SINGLE NORMAL < dbl_res24 && dbl_res24 < POSINFF) { 
result_huge = 1; 


} 


// at this point, there are no enabled I,D, or Z exceptions 

// to take; the instr. 

// might lead to an enabled underflow, enabled underflow and inexact, 
// enabled overflow, enabled overflow and inexact, enabled inexact, or 
// none of these; if there are no U or O enabled exceptions, re-execute 
// the instruction using IA-32 double precision format, and the 

// user's rounding mode; exceptions must have 

// been disabled before calling 

// this function; an inexact exception may be reported on the 53-bit 

// fsubp, fmulp, or on both the 53-bit and 24-bit conversions, while an 
// overflow or underflow (with traps disabled) may be reported on the 
// conversion from dbl_res to res 


// check whether there is an underflow, overflow, 

// or inexact trap to be taken 

// if the underflow traps are enabled and the result is 
// tiny, take underflow trap 


if (!(exc_env->exc_masks & UNDERFLOW MASK) && result_tiny) { 
dbl_res24 = TWO TO 192 * dbl_res24; // exact 
exc_env->status_flag_underflow = 1; 
exc_env->exception_cause = UNDERFLOW; 
exc_env->result_fval = (float)dbl_res24; // exact 
if (sw & PRECISION MASK) exc_env->status_flag_inexact = 1; 
return (RAISE EXCEPTION) ; 


} 


// if overflow traps are enabled and the result is huge, take 
// overflow trap 
if (!(exc_env->exc_masks & OVERFLOW MASK) && result_huge) { 
dbl_res24 = TWO_TO M192 * dbl_res24; // exact 
exc_env->status_flag_ overflow = 1; 
exc_env->exception_cause = OVERFLOW; 
exc_env->result_fval = (float)dbl_res24; // exact 
if (sw & PRECISION MASK) exc_env->status_flag_inexact = 1; 
return (RAISE EXCEPTION) ; 


// set control word with rounding mode set to exc_env->rounding_ mode, 
// double precision, and all exceptions disabled 
cw = cw | 0200H; // set precision to double 
__asm { 
fldcw WORD PTR cw; 


} 


switch (exc_env->operation) { 


case ADDPS: 
case ADDSS: 
// perform the addition 
__asm { 
// load input operands 
fld DWORD PTR uiopdi; // may set the denormal status flag 
fld DWORD PTR uiopd2; // may set the denormal status flag 
faddp st(1), st(0); // rounded to 53 bits, may set the inexact 
// status flag 
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// store result 
fstp QWORD PTR dbl_res; // exact, will not set any flag 


} 


break; 


case SUBPS: 
case SUBSS: 
// perform the subtraction 
__asm { 
// load input operands 
fld DWORD PTR uiopdi; // may set the denormal status flag 
fld DWORD PTR uiopd2; // may set the denormal status flag 
fsubp st(1), st(0); // rounded to 53 bits, may set the inexact 
// status flag 


// store result 
fstp QWORD PTR dbl_res; // exact, will not set any flag 


} 


break; 


case MULPS: 
case MULSS: 
// perform the multiplication 
__asm { 
// load input operands 
fld DWORD PTR uiopdl1; // may set the denormal status flag 
fld DWORD PTR uiopd2; // may set the denormal status flag 
fmulp st(1), st(0); // rounded to 53 bits, exact 
// store result 
fstp QWORD PTR dbl_res; // exact, will not set any flag 


} 


break; 


case DIVPS: 
case DIVSS: 
// perform the division 
__asm { 
// load input operands 
fld DWORD PTR uiopdl1; // may set the denormal status flag 
fld DWORD PTR uiopd2; // may set the denormal status flag 
fdivp st(1), st(0); // vounded to 53 bits, may set the inexact 
// status flag 


// store result 
fstp QWORD PTR dbl_res; // exact, will not set any flag 


} 


break; 


default: 
; // will never occur 


} 


// calculate result for the case an inexact trap has to be taken, or 
// when no trap occurs (second IEEE rounding) 
res = (float)dbl_ res; 

// may set P, U or O; may also involve denormalizing the result 


// vead status word 
__asm { 
fstsw WORD PTR sw; 


} 


// if inexact traps are enabled and result is inexact, take inexact trap 


if (!(exc_env->exc_masks & PRECISION MASK) && 
((sw & PRECISION MASK) || (exc_env->ftz && result_tiny))) { 
exc_env->status_flag_ inexact = 1; 
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exc_env->exception_cause = INEXACT; 
if (result_tiny) { 
exc_env->status_flag_underflow = 1; 


// if ftz = 1 and result is tiny, result = 0.0 
// (no need to check for underflow traps disabled: result tiny and 
// underflow traps enabled would have caused taking an underflow 
// trap above) 
if (exc_env->ftz) { 
if (res > 0.0) 
res = ZEROF; 
else if (res < 0.0) 
res = NZEROF; 
// else leave res unchanged 
} 
} 


if (result_huge) exc_env->status_flag_ overflow = 1; 
exc_env->result_fval = res; 
return (RAISE EXCEPTION) ; 


// if it got here, then there is no trap to be taken; the following must 
// hold: ((the MXCSR U exceptions are disabled or 


// the MXCSR underflow exceptions are enabled and the underflow flag is 
// clear and (the inexact flag is set or the inexact flag is clear and 
// the 24-bit result with unbounded exponent is not tiny) )) 

// and (the MXCSR overflow traps are disabled or the overflow flag is 
// clear) and (the MXCSR inexact traps are disabled or the inexact flag 
// is clear) 


// in this case, the result has to be delivered (the status flags are 
// sticky, so they are all set correctly already) 


// vead status word to see if result is inexact 
__asm { 
fstsw WORD PTR sw; 


if (sw & UNDERFLOW_MASK) exc_env->status_flag_underflow = 1; 
if (sw & OVERFLOW_MASK) exc_env->status_flag_ overflow = 1; 
if (sw & PRECISION MASK) exc_env->status_flag_inexact = 1; 
// if ftz = 1, and result is tiny (underflow traps must be disabled), 
// result = 0.0 
if (exc_env->ftz && result_tiny) { 
if (res > 0.0) 
res = ZEROF; 
else if (res < 0.0) 
res = NZEROF; 
// else leave res unchanged 


exc_env->status_flag_ inexact = 1; 
exc_env->status_flag_underflow = 1; 


exc_env->result_fval = res; 

if (sw & ZERODIVIDE MASK) exc_env->status_flag_divide_by zero = 1; 
(sw & DENORMAL MASK) exc_env->status_flag_ denormal= 1; 

if (sw & INVALID MASK) exc_env->status_flag_invalid_operation = 1; 
return (DO NOT RAISE EXCEPTION) ; 


break; 


case CMPPS: 
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case CMPSS: 


break; 


case COMISS: 
case UCOMISS: 


break; 


case CVTPI2PS: 
case CVTSI2SS: 


break; 


case CVTPS2PI: 
case CVTSS2SI: 
case CVTTPS2PI: 
case CVTTSS2SI1: 


break; 


case MAXPS: 
case MAXSS: 
case MINPS: 
case MINSS: 


break; 


case SORTPS: 
case SORTSS: 


break; 


case UNSPEC: 


break; 


default: 
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Exception priority, floating-point exceptions, 4-23 
Exception-flag masks, x87 FPU control word, 8-7 
Exceptions 
64-bit mode, 6-19 
description of, 6-12 
handler, 6-12 
implicit call to handler, 6-1 
in real-address mode, 6-18 
notation, 1-8 
Exponent, floating-point number, 4-11 


F 


F2XM1 instruction, 8-21 
FABS instruction, 8-17 
FADD instruction, 8-17 
FADDP instruction, 8-17 
Far call 
description of, 6-4 
operation, 6-5 
Far pointer 
16-bit addressing, 3-9 
32-bit addressing, 3-9 
64-bit mode, 4-7 
description of, 3-7, 4-6 
legacy modes, 4-6 
Far return operation, 6-5 
FBLD instruction, 8-16 
FBSTP instruction, 8-16 
FCHS instruction, 8-17 
FCLEX/FNCLEX instructions, 8-5 
FCMOVcc instructions, 8-7, 8-16 
FCOM instruction, 8-6, 8-18 
FCOMI instruction, 8-7, 8-19 
FCOMIP instruction, 8-7, 8-19 
FCOMP instruction, 8-6, 8-18 
FCOMPP instruction, 8-6, 8-18 
FCOS instruction, 8-5, 8-20 
FDIV instruction, 8-17 
FDIVP instruction, 8-17 
FDIVR instruction, 8-17 
FDIVRP instruction, 8-17 
Feature determination, of processor, 20-1 
FIADD instruction, 8-17 
FICOM instruction, 8-6, 8-18 
FICOMP instruction, 8-6, 8-18 
FIDIV instruction, 8-17 
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FIDIVR instruction, 8-17 
FILD instruction, 8-16 
FIMUL instruction, 8-17 
FINIT/FNINIT instructions, 8-5, 8-7, 8-8, 8-23 
FIST instruction, 8-16 
FISTP instruction, 8-16 
FISTTP instruction, 5-22, 12-3 
FISUB instruction, 8-17 
FISUBR instruction, 8-17 
Flags 
cross-reference with instructions, A-1 
Flat memory model, 3-7, 3-13 
FLD instruction, 8-16 
FLD1 instruction, 8-17 
FLDCW instruction, 8-7, 8-23 
FLDENV instruction, 8-5, 8-9, 8-11, 8-23 
FLDL2E instruction, 8-17 
FLDL2T instruction, 8-17 
FLDLG2 instruction, 8-17 
FLDLN2 instruction, 8-17 
FLDPI instruction, 8-17 
FLDSW instruction, 8-23 
FLDZ instruction, 8-17 
Floating-point data types 
biasing constant, 4-6 
denormalized finite number, 4-5 
description of, 4-4 
double extended precision format, 4-4, 4-5 
double precision format, 4-4, 4-5 
infinites, 4-5 
normalized finite number, 4-5 
single precision format, 4-4, 4-5 
SSE extensions, 10-5 
SSE2 extensions, 11-3 
storing in memory, 4-6 
x87 FPU, 8-13 
zeros, 4-5 
Floating-point exception handlers 
SSE and SSE2 extensions, 11-17, 11-18 
typical actions, 4-23 
x87 FPU, 8-32 
Floating-point exceptions 
denormal operand exception (#D), 4-20, 8-28, 11-15, C-1 
divide by zero exception (#2), 4-20, 8-28, 11-15, C-1 
exception conditions, 4-20 
exception priority, 4-23 
inexact result (precision) exception (#P), 4-22, 8-30, 11-16, C-1 
invalid operation exception (#1), 4-20, 8-26, 11-14 
invalid-operation exception (#IA), C-1 
invalid-operation exception (#IS), C-1 
invalid-operation exception (#1), C-1 
numeric overflow exception (#0), 4-21, 8-28, 11-15, C-1 
numeric underflow exception (#U), 4-21, 8-29, 11-16, C-1 
summary of, 4-18, C-1 
typical handler actions, 4-23 
Floating-point format 
biased exponent, 4-13 
description of, 8-13 
exponent, 4-11 
fraction, 4-11 
indefinite, 4-5 
QNaN floating-point indefinite, 4-17 
real number system, 4-11 
sign, 4-11 
significand, 4-11 
Floating-point numbers 
defined, 4-11 
encoding, 4-5 
Flush-to-zero 
FTZ flag, MXCSR register, 10-4, 11-2 
mode, 10-4 
FMA operation, 14-22, 14-23 


FMUL instruction, 8-17 

FMULP instruction, 8-17 

FNOP instruction, 8-23 

Fopcode compatibility mode, 8-10 

FPATAN instruction, 8-20, 8-21 

FPREM instruction, 8-5, 8-18, 8-21 

FPREM1 instruction, 8-5, 8-18, 8-21 

FPTAN instruction, 8-5 

Fraction, floating-point number, 4-11 

FRNDINT instruction, 8-18 

FRSTOR instruction, 8-5, 8-9, 8-11, 8-23 

FS register, 3-13, 3-14 

FSAVE/FNSAVE instructions, 8-4, 8-5, 8-9, 8-11, 8-23 
FSCALE instruction, 8-21 

FSIN instruction, 8-5, 8-20 

FSINCOS instruction, 8-5, 8-21 

FSQRT instruction, 8-18 

FST instruction, 8-16 

FSTCW/FNSTCW instructions, 8-7, 8-23 
FSTENV/FNSTENV instructions, 8-4, 8-9, 8-11, 8-23 
FSTP instruction, 8-16 

FSTSW/FNSTSW instructions, 8-4, 8-23 

FSUB instruction, 8-17 

FSUBP instruction, 8-17 

FSUBR instruction, 8-17 

FSUBRP instruction, 8-17 

FTST instruction, 8-6, 8-19 

FUCOM instruction, 8-18 

FUCOMI instruction, 8-7, 8-19 

FUCOMIP instruction, 8-7, 8-19 

FUCOMP instruction, 8-18 

FUCOMPP instruction, 8-6, 8-18 

FXAM instruction, 8-4, 8-19 

FXCH instruction, 8-16 

FXRSTOR instruction, 5-13, 8-12, 10-14, 11-23 
FXSAVE instruction, 5-13, 8-12, 10-14, 11-23 
FXTRACT instruction, 8-18 

FYL2X instruction, 8-21 

FYL2XP1 instruction, 8-21 


G 
GDTR register, 3-4, 3-6 
General purpose registers 
64-bit mode, 3-5, 3-13 
description of, 3-11 
overview of, 3-2, 3-5 
parameter passing, 6-7 
part of basic programming environment, 7-1 
using REX prefix, 3-13 
General-purpose instructions 
64-bit mode, 7-1 
basic programming environment, 7-1 
data types operated on, 7-1, 7-2 
description of, 7-1 
origin of, 7-1 
programming with, 7-1 
summary of, 5-4, 7-2 
GS register, 3-13, 3-14 


H 
HADDPD instruction, 5-23, 12-4 
HADDPS instruction, 5-22, 12-4 
Hardware Lock Elision (HLE), 16-2 
Hexadecimal numbers, 1-7 
Horizontal processing model, 12-1 
HSUBPD instruction, 5-23, 12-5 
HSUBPS instruction, 5-22, 12-4 
HT Technology 
first processor, 2-3 
implementing, 2-17 


introduction, 2-16 


I 


IA-32 architecture 
history of, 2-1 
introduction to, 2-1 
|A-32e mode 
introduction, 2-20 
segmentation, 3-22 
See also: 64-bit mode, compatibility mode 
IA32_MISC_ENABLE MSR, 8-10 
ID (identification) flag, EFLAGS register, 3-17 
IDIV instruction, 7-9 
IDTR register, 3-4, 3-6 
IE (invalid operation exception) flag 
MXCSR register, 11-14 
x87 FPU status word, 8-5, 8-27 
IEEE Standard 754, 4-4, 4-11, 8-1 
IF (interrupt enable) flag 
EFLAGS register, 3-17, 6-13, 19-4, A-1 
IM (invalid operation exception) mask bit 
MXCSR register, 11-14 
x87 FPU control word, 8-7 
Immediate operands, 3-20 
IMUL instruction, 7-9 
IN instruction, 5-8, 7-20, 19-3 
INC instruction, 7-8 
Indefinite 
description of, 4-17, 14-18 
floating-point format, 4-5, 4-13 
integer, 4-4, 8-14 
packed BCD integer, 4-11 
QNaN floating-point, 4-17 
Index (operand addressing), 3-22, 3-23, 3-24 
Inexact result (precision) 
exception (#P), overview, 4-22 
exception (#P), SSE-SSE2 extensions, 11-16 
exception (#P), x87 FPU, 8-30 
on floating-point operations, 4-18 
Infinity control flag, x87 FPU control word, 8-8 
Infinity, floating-point format, 4-5, 4-15 
INIT pin, 3-15 
Input/output (see I/O) 
INS instruction, 5-8, 7-20, 19-3 
Instruction operands, 1-6 
Instruction pointer 
64-bit mode, 7-2 
EIP register, 3-11, 3-18 
RIP register, 3-18 
RIP, EIP, IP compared, 3-10 
x87 FPU, 8-9 
Instruction prefixes 
effect on SSE and SSE2 instructions, 11-25 
REX prefix, 3-2, 3-12 
Instruction set 
binary arithmetic instructions, 7-8 
bit scan instructions, 7-14 
bit test and modify instructions, 7-14 
byte-set-on-condition instructions, 7-14 
cacheability control instructions, 5-18, 5-21 
comparison and sign change instruction, 7-8 
control transfer instructions, 7-14 
data movement instructions, 7-2 
decimal arithmetic instructions, 7-9 
EFLAGS cross-reference, A-1 
EFLAGS instructions, 7-21 
exchange instructions, 7-4 
FXSAVE and FXRSTOR instructions, 5-13 
general-purpose instructions, 5-4 
grouped by processor, 5-1, 5-2 
increment and decrement instructions, 7-8 
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instruction ordering instructions, 5-18, 5-21 
I/O instructions, 5-8, 7-20 

logical instructions, 7-10 

MMxX instructions, 5-13, 9-5 

multiply and divide instructions, 7-9 
processor identification instruction, 7-23 
repeating string operations, 7-19 

rotate instructions, 7-13 

segment register instructions, 7-22 
shift instructions, 7-10 

SIMD instructions, introduction to, 2-14 
software interrupt instructions, 7-17 
SSE instructions, 5-15 

SSE2 instructions, 5-18 

stack manipulation instructions, 7-5 
string operation instructions, 7-18 
summary, 5-1 

system instructions, 5-30, 5-34 

test instruction, 7-14 

type conversion instructions, 7-7 


x87 FPU and SIMD state management instructions, 5-13 


x87 FPU instructions, 5-10 
INT instruction, 6-18, 7-23 
Integers 
description of, 4-3 
indefinite, 4-4, 8-14 
signed integer encodings, 4-4 
signed, description of, 4-4 
unsigned integer encodings, 4-3 
unsigned, description of, 4-3 
Intel 64 architecture 
64-bit mode, 3-1 
64-bit mode instructions, 5-35 
address space, 3-6 
compatibility mode, 3-1 
data types, 4-1 
executing calls, 6-1 
general purpose instructions, 7-1 
generations, 2-20 
history of, 2-1 
IA32e mode, 3-1 
introduction, 2-20 
memory organization, 3-6, 3-8 
See also: IA-32e mode 
Intel Advanced Digital Media Boost, 2-4, 2-11 
Intel Advanced Smart Cache, 2-10 
Intel Advanced Thermal Manager, 2-4 
Intel Core 2 Extreme processor family, 2-4, 2-18 
Intel Core Duo processor, 2-4, 2-18 
Intel Core microarchitecture, 2-4, 2-10, 2-12, 2-13, 2-18 
Intel Core Solo processor, 2-4 
Intel Dynamic Power Coordination, 2-4 
Intel NetBurst microarchitecture, 1-3 
description of, 2-8 
introduction, 2-8 
Intel Pentium D processor, 2-18 
Intel Pentium processor Extreme Edition, 2-18 
Intel Smart Cache, 2-4 
Intel Smart Memory Access, 2-4, 2-11 
Intel software network link, 1-9 
Intel Transactional Synchronization, 15-3, 16-1 
Intel VTune Performance Analyzer 
related information, 1-9 
Intel Wide Dynamic Execution, 2-4, 2-10, 2-12, 2-13 
Intel Xeon processor, 1-1 
description of, 2-3 
Intel Xeon processor 5100 series, 2-4, 2-18 
Intel386 processor, 2-1 
Intel486 processor 
history of, 2-1 
Inter-privilege level call 
description of, 6-7 
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operation, 6-8 
Inter-privilege level return 
description of, 6-7 
operation, 6-8 
Interrupt gate, 6-13 
Interrupt handler, 6-12 
Interrupts 
64-bit mode, 6-19 
description of, 6-12 
handler, 6-12 
implicit call to an interrupt handler 
procedure, 6-13 
implicit call to an interrupt handler task, 6-18 
implicit call to interrupt handler procedure, 6-13 
implicit call to interrupt handler task, 6-18 
in real-address mode, 6-18 
maskable, 6-13 
INTn instruction, 7-17 
INTO instruction, 6-18, 7-18, 7-23 
Invalid arithmetic operand exception (#IA) 
description of, 8-27 
masked response to, 8-27 
Invalid operation exception (#1) 
overview, 4-20 
SSE and SSE2 extensions, 11-14 
x87 FPU, 8-26 
IOPL (I/O privilege level) field 
EFLAGS register, 3-17, 19-3 
IRET instruction, 3-18, 6-17, 6-18, 7-15, 7-23, 19-4 
1/0 
address space, 19-1 
instruction serialization, 19-5 
instructions, 5-8, 7-20, 19-3 
I/O privilege level (see IOPL) 
map base, 19-4 
permission bit map, 19-4 
ports, 3-4, 19-1, 19-2, 19-3, 19-5 
sensitive instructions, 19-3 


J 

J-bit, 4-11 

Jcc instructions, 3-17, 3-18, 7-15 
JMP instruction, 3-18, 7-15, 7-22 


L 
L1 (level 1) cache, 2-7, 2-9 
L2 (level 2) cache, 2-7, 2-9 
LAHF instruction, 3-15, 7-21 
Last instruction opcode, x87 FPU, 8-10 
LDDQU instruction, 5-22, 12-3 
LDMXCSR instruction, 10-12, 11-24 
LDS instruction, 7-23 
LDTR register, 3-4, 3-6 
LEA instruction, 7-23 
LEAVE instruction, 6-20, 6-24, 7-21 
LES instruction, 7-23 
LFENCE instruction, 11-12 
LGS instruction, 7-23 
Linear address, 3-7 
Linear address space 

defined, 3-7 

maximum size, 3-7 
LOCK signal, 7-4 
LODS instruction, 3-17, 7-18 
Log epsilon, x87 FPU operation, 8-21 
Logical address, 3-7 
LOOP instructions, 7-16 
LOOPcc instructions, 3-17, 7-16 
LSS instruction, 7-23 


M 


Machine check registers, 3-4 
Maskable interrupts, 6-13 
Masked responses 
denormal operand exception (#D), 4-20, 8-28 
divide by zero exception (#Z), 4-21, 8-28 
inexact result (precision) exception (#P), 4-22, 8-30 
invalid arithmetic operation (#IA), 8-27 
invalid operation exception (#1), 4-20 
numeric overflow exception (#0), 4-21, 8-29 
numeric underflow exception (#U), 4-22, 8-29 
stack overflow or underflow 
exception (#IS), 8-27 
MASKMOVDQU instruction, 11-12, 11-25 
MASKMOVQ instruction, 10-12, 11-25 
Masks, exception-flags 
MXCSR register, 10-4 
x87 FPU control word, 8-7 
MAXPD instruction, 11-6 
MAXPS instruction, 10-8 
MAXSD instruction, 11-6 


MAXSD- Return Maximum Scalar Double-Precision Floating-Point Value, 


15-3 
MAXSS instruction, 10-9 
Memory 
flat memory model, 3-7 
management registers, 3-4 
memory type range registers (MTRRs), 3-4 
modes of operation, 3-9 
organization, 3-6, 3-7 
physical, 3-6 
real address mode memory model, 3-7, 3-8 
segmented memory model, 3-7 
virtual-8086 mode memory model, 3-7, 3-8 
Memory operands 
64-bit mode, 3-21 
legacy modes, 3-21 
Memory-mapped I/O, 19-2 
MFENCE instruction, 11-12, 11-25 
Microarchitecture 
(see Intel NetBurst microarchitecture) 
(see P6 family microarchitecture) 
MINPD instruction, 11-6 
MINPS instruction, 10-9 
MINSD instruction, 11-7 
MINSS instruction, 10-9 
MMxX instruction set 
arithmetic instructions, 9-6 
comparison instructions, 9-7 
conversion instructions, 9-7 
data transfer instructions, 9-6 
EMMS instruction, 9-8 
logical instructions, 9-7 
overview, 9-5 
shift instructions, 9-8 
MMX registers 
description of, 9-2 
overview of, 3-2 
MMX technology 
64-bit mode, 9-2 
64-bit packed SIMD data types, 4-8 
compatibility mode, 9-2 
compatibility with FPU architecture, 9-8 
data types, 9-3 
detecting MMX technology with CPUID instruction, 9-8 
effect of instruction prefixes on MMX instructions, 9-11 
exception handling in MMX code, 9-11 
IA-32e mode, 9-2 
instruction set, 5-13, 9-5 
interfacing with MMX code, 9-10 
introduction to, 9-1 
memory data formats, 9-3 


mixing MMX and floating-point instructions, 9-10 
MMxX registers, 9-2 

programming environment (overview), 9-1 
register mapping, 9-11 

saturation arithmetic, 9-4 

SIMD execution environment, 9-4 

transitions between x87 FPU - MMX code, 9-9 
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updating MMX technology routines using 128-bit SIMD integer 


instructions, 11-24 


using MMX code in a multitasking operating system environment, 9-10 


using the EMMS instruction, 9-9 
wraparound mode, 9-4 
Model-specific registers (see MSRs) 
Modes of operation 
64-bit mode, 3-1 
compatibility mode, 3-1 
memory models used with, 3-9 
overview, 3-1, 3-5 
protected mode, 3-1 
real address mode, 3-1 
system management mode (SMM), 3-1 
MONITOR instruction, 5-23, 12-5 
Moore's law, 2-20 
MOV instruction, 7-3, 7-22 
MOVAPD instruction, 11-5, 11-23 
MOVAPS instruction, 10-7, 11-23 
MOVD instruction, 9-6 
MOVDDUP instruction, 5-23, 12-3 
MOVDQ2Q instruction, 11-11 
MOVDOQA instruction, 11-11, 11-23 
MOVDQU instruction, 11-11, 11-23 
MOVHLPS instruction, 10-8 
MOVHPD instruction, 11-6 
MOVHPS instruction, 10-8 
MOVLHPS instruction, 10-8 
MOVLPD instruction, 11-6 
MOVLPS instruction, 10-7 
MOVMSKPD instruction, 11-6 
MOVMSKPS instruction, 10-8 
MOVNTDQ instruction, 11-12, 11-25 
MOVNTI instruction, 11-12, 11-25 
MOVNTPD instruction, 11-12, 11-25 
MOVNTPS instruction, 10-12, 11-25 
MOVNTQ instruction, 10-12, 11-25 
MOVQ instruction, 9-6 
MOVQ2DQ instruction, 11-11 
MOVS instruction, 3-17, 7-18 
MOVSD instruction, 11-6, 11-23 
MOVSHDUP instruction, 5-23, 12-3 
MOVSLDUP instruction, 5-23, 12-3 
MOVSS instruction, 10-7, 11-23 
MOVSX instruction, 7-8 
MOVSXD instruction, 7-8 
MOVUPD instruction, 11-6, 11-23 
MOVUPS instruction, 10-6, 10-7, 11-23 
MOVZX instruction, 7-8 
MS-DOS compatibility mode, 8-32 
MSRs, 3-4 
MTRRs, 3-4 
MUL instruction, 7-9 
MULPD instruction, 11-6 
MULPS instruction, 10-8 
MULSD instruction, 11-6 
MULSS instruction, 10-8 
Multi-core technology, 2-18 
Multi-threading capability, 2-18 
MWAIT instruction, 5-23, 12-5 
MXCSR register, 11-16 
denormals-are-zero (DAZ) flag, 10-5, 11-2, 11-3 
description, 10-3 
flush-to-zero flag (FTZ), 10-4 
FXSAVE and FXRSTOR instructions, 11-23 
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LDMXCSR instruction, 11-24 

load and store instructions, 10-12 

RC field, 4-18 

saving on a procedure or function call, 11-23 

SIMD floating-point mask and flag bits, 10-4 

SIMD floating-point rounding control field, 10-4 

state management instructions, 5-18, 10-12 

STMXCSR instruction, 11-24 

writing to while preventing general-protection exceptions (#GP), 
11-21 


NaNs 

description of, 4-13, 4-15 

encoding of, 4-5, 4-14 

SNaNs vs. QNaNs, 4-15 
Near call 

description of, 6-4 

operation, 6-4 
Near pointer 

64-bit mode, 4-7 

legacy modes, 4-6 
Near return operation, 6-4 
NEG instruction, 7-8 
NetBurst microarchitecture (see Intel NetBurst microarchitecture) 
Non-arithmetic instructions, x87 FPU, 8-25 
Non-number encodings, floating-point format, 4-13 
Non-temporal data 

caching of, 10-12 

description, 10-12 

temporal vs. non-temporal data, 10-12 
Non-waiting instructions, x87 FPU, 8-24, 8-32 
NOP instruction, 7-23 
Normalized finite number, 4-5, 4-13, 4-14 
NOT instruction, 7-10 
Notation 

bit and byte order, 1-5 

exceptions, 1-8 

hexadecimal and binary numbers, 1-7 

instruction operands, 1-6 

notational conventions, 1-5 

reserved bits, 1-6 

segmented addressing, 1-7 
NT (nested task) flag, EFLAGS register, 3-17, A-1 
Numeric overflow exception (#0) 

overview, 4-21 

SSE and SSE2 extensions, 11-15 

x87 FPU, 8-4, 8-28 
Numeric underflow exception (#U) 

overview, 4-21 

SSE and SSE2 extensions, 11-16 

x87 FPU, 8-4, 8-29 


O 
OE (numeric overflow exception) flag 
MXCSR register, 11-15 
x87 FPU status word, 8-5, 8-29 
OF (overflow) flag 
EFLAGS register, 3-16, 6-18 
OF (overflow) flag, EFLAGS register, A-1 
Offset (operand addressing, 64-bit mode), 3-24 
Offset (operand addressing), 3-22 
OM (numeric overflow exception) mask bit 
MXCSR register, 11-15 
x87 FPU control word, 8-7, 8-29 
Operand 
addressing, modes, 3-19 
instruction, 1-6 
size attribute, 3-18 
sizes, 3-9, 3-19 
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x87 FPU instructions, 8-15 
OR instruction, 7-10 
Ordering I/O, 19-5 
ORPD instruction, 11-7 
ORPS instruction, 10-9 
OSXMMEXCPT flag 

control register CR4, 11-18 
OUT instruction, 5-8, 7-20, 19-3 
OUTS instruction, 5-8, 7-20, 19-3 
Overflow exception (HOF), 6-18 
Overflow, x87 FPU stack, 8-26 


P 


P6 family microarchitecture 

description of, 2-7 

history of, 2-2 
P6 family processors 

description of, 1-1 

history of, 2-2 

P6 family microarchitecture, 2-7 
PABSB instruction, 5-24, 12-7 
PABSD instruction, 12-8 
PABSW instruction, 5-24, 12-8 
Packed 

BCD integer indefinite, 4-11 

BCD integers, 4-10 

bytes, 9-3 

doublewords, 9-3 

SIMD data types, 4-8 

SIMD floating-point values, 4-8 

SIMD integers, 4-8 

words, 9-3 
PACKSSWB instruction, 9-7 
PACKUSWB instruction, 9-7 
PADDB instruction, 9-6 
PADDD instruction, 9-6 
PADDQ instruction, 11-11 
PADDSB instruction, 9-7 
PADDSwW instruction, 9-7 
PADDUSB instruction, 9-7 
PADDUSW instruction, 9-7 
PADDW instruction, 9-6 
PALIGNR instruction, 5-24, 12-8 
PAND instruction, 9-7 
PANDN instruction, 9-7 
Parameter passing 

argument list, 6-7 

on stack, 6-7 

on the stack, 6-7 


through general-purpose registers, 6-7 


x87 FPU register stack, 8-3 

XMM registers, 11-23 
PAUSE instruction, 11-12 
PAVGB instruction, 10-11 


PC (precision) field, x87 FPU control word, 8-7 


PCMPEQB instruction, 9-7 
PCMPEQD instruction, 9-7 
PCMPEQW instruction, 9-7 
PCMPGTB instruction, 9-7 
PCMPGTD instruction, 9-7 
PCMPGTW instruction, 9-7 


PE (inexact result exception) flag, 11-16 


MXCSR register, 4-18 


x87 FPU status word, 4-18, 8-4, 8-5, 8-30 


Pentium 4 processor, 1-1 
description of, 2-3, 2-4 


Pentium 4 processor supporting Hyper-Threading Technology 


description of, 2-3, 2-4 
Pentium II processor, 1-3 

description of, 2-2 

P6 family microarchitecture, 2-7 


Pentium Il Xeon processor 
description of, 2-2 
Pentium Ill processor, 1-3 
description of, 2-2 
P6 family microarchitecture, 2-7 
Pentium Ill Xeon processor 
description of, 2-3 
Pentium M processor 
description of, 2-3 
instructions supported, 2-3 
Pentium Pro processor, 1-3 
description of, 2-2 
P6 family microarchitecture, 2-7 
Pentium processor, 1-1 
history of, 2-2 
Pentium processor Extreme Edition 
introduction, 2-4 
Pentium processor with MMX technology, 2-2 
Performance monitoring counters, 3-4 
PEXTRW instruction, 10-11 
PF (parity) flag, EFLAGS register, 3-16, A-1 
PHADDD instruction, 5-23, 12-7 
PHADDSwW instruction, 5-23, 12-7 
PHADDwW instruction, 5-23, 12-7 
PHSUBD instruction, 5-24, 12-7 
PHSUBSwW instruction, 5-24, 12-7 
PHSUBW instruction, 5-23, 12-7 
Physical 
address space, 3-6 
memory, 3-6 
PINSRW instruction, 10-11 
Pi, x87 FPU constant, 8-21 
PM (inexact result exception) mask bit 
MXCSR register, 11-16 
x87 FPU control word, 8-7, 8-30 
PMADDUBSW instruction, 5-24, 12-8 
PMADDWD instruction, 9-7 
PMAXSW instruction, 10-11 
PMAXUB instruction, 10-11 
PMINSW instruction, 10-11 
PMINUB instruction, 10-11 
PMOVMSKEB instruction, 10-11 
PMULHRSW instruction, 5-24, 12-8 
PMULHUW instruction, 10-12 
PMULUDQ instruction, 11-11 
Pointer data types, 4-6, 4-7 
Pointers 
64-bit mode, 4-7 
far pointer, 4-6 
near pointer, 4-6 
POP instruction, 6-1, 6-2, 7-6, 7-22 
POPA instruction, 6-7, 7-6 
POPF instruction, 3-15, 6-7, 7-21, 19-4 
POPFD instruction, 3-15, 6-7, 7-21 
POR instruction, 9-7 
Power coordination, 2-4 
PREFETCHh instructions, 10-13, 11-25 
Privilege levels 
description of, 6-8 
inter-privilege level calls, 6-7 
protection rings, 6-8 
stack switching, 6-14 
Procedure calls 
description of, 6-4 
far call, 6-4 
for block-structured languages, 6-20 
inter-privilege level call, 6-8 
linking, 6-3 
near call, 6-4 
overview, 6-1 
return instruction pointer (EIP register), 6-3 
saving procedure state information, 6-7 


stack, 6-1 
stack switching, 6-8 
to exception handler procedure, 6-13 
to exception task, 6-18 
to interrupt handler procedure, 6-13 
to interrupt task, 6-18 
to other privilege levels, 6-7 
types of, 6-1 
Processor identification 
earlier Intel architecture processors, 20-1 
early processors, 20-1 
notes on where to start, 20-1 
using CPUID, 20-1 
using CPUID instruction, 20-1 
Processor state information, saving, 6-7 
Protected mode 
1/0, 19-3 
memory models used, 3-9 
overview, 3-1 
Protection rings, 6-8 
PSADBwW instruction, 10-12 
PSHUFB instruction, 5-24, 12-8 
PSHUFD instruction, 11-11 
PSHUFHW instruction, 11-11 
PSHUFLW instruction, 11-11 
PSHUFW instruction, 10-12, 11-11 
PSIGNB/W/D instruction, 5-24, 12-8 
PSLLD instruction, 9-8 
PSLLDQ instruction, 11-11 
PSLLQ instruction, 9-8 
PSLLW instruction, 9-8 
PSRLDQ instruction, 11-11 
PSUBB instruction, 9-6 
PSUBD instruction, 9-6 
PSUBQ instruction, 11-11 
PSUBSB instruction, 9-7 
PSUBSW instruction, 9-7 
PSUBUSSB instruction, 9-7 
PSUBUSW instruction, 9-7 
PSUBW instruction, 9-6 
PUNPCKHBW instruction, 9-7 
PUNPCKHDOQ instruction, 9-7 
PUNPCKHQDO instruction, 11-11 
PUNPCKHWD instruction, 9-7 
PUNPCKLBW instruction, 9-7 
PUNPCKLDQ instruction, 9-7 
PUNPCKLQDQ instruction, 11-11 
PUNPCKLWD instruction, 9-7 
PUSH instruction, 6-1, 6-2, 7-5, 7-22 
PUSHA instruction, 6-7, 7-5 
PUSHF instruction, 3-15, 6-7, 7-21 
PUSHFD instruction, 3-15, 6-7, 7-21 
PXOR instruction, 9-7 


Q 
QNaN floating-point indefinite, 4-5, 4-17, 8-14 
QNaNs 
description of, 4-15 
effect on COMISD and UCOMISD, 11-7 
encodings, 4-5 
operating on, 4-16 
rules for generating, 4-16 
using in applications, 4-16 
Quadword, 4-1, 9-3 
Quiet NaN (see QNaN) 
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R8D-R15D registers, 3-12 
R8-R15 registers, 3-12 
RAX register, 3-12 
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RBP register, 3-12, 6-4 
RBX register, 3-12 
RC (rounding control) field 
MXCSR register, 4-18, 10-4 
x87 FPU control word, 4-18, 8-8 
RCL instruction, 7-13 
RCPPS instruction, 10-8 
RCPSS instruction, 10-8 
RCR instruction, 7-13 
RCX register, 3-12 
RDI register, 3-12 
RDRAND, 7-24 
RDX register, 3-12 
Real address mode 
handling exceptions in, 6-18 
handling interrupts in, 6-18 
memory model, 3-7, 3-8 
memory model used, 3-9 
not in 64-bit mode, 3-9 
overview, 3-1 
Real numbers 
continuum, 4-11 
encoding, 4-13, 4-14 
notation, 4-12, 14-18 
system, 4-11 
Register operands 
64-bit mode, 3-21 
legacy modes, 3-20 
Register stack, x87 FPU, 8-1 
Registers 
64-bit mode, 3-12, 3-15 
control registers, 3-4 
CR in 64-bit mode, 3-5 
debug registers, 3-4 
EFLAGS register, 3-11, 3-15 
EIP register, 3-11, 3-18 
general purpose registers, 3-11 
instruction pointer, 3-11 
machine check registers, 3-4 
memory management registers, 3-4 
MMX registers, 3-2, 9-2 
MSRs, 3-4 
MTRRs, 3-4 
MXCSR register, 10-4 
performance monitoring counters, 3-4 
REX prefix, 3-12 
segment registers, 3-11, 3-13 
x87 FPU registers, 8-1 
XMM registers, 3-2, 10-3 
Related literature, 1-9 
REP/REPE/REPZ/REPNE/REPNZ 
prefixes, 7-19, 19-3 
Reserved bits, 1-6 
RESET pin, 3-15 
RET instruction, 3-18, 6-3, 6-4, 7-15, 7-22 
Return instruction pointer, 6-3 
Returns, from procedure calls 
exception handler, return from, 6-13 
far return, 6-5 
inter-privilege level return, 6-8 
interrupt handler, return from, 6-13 
near return, 6-4 
REX prefixes, 3-2, 3-12, 3-19 
RF (resume) flag, EFLAGS register, 3-17, A-1 
RFLAGS, 3-18 
RFLAGS register, 7-22 
See EFLAGS register 
RIP register, 6-4 
64-bit mode, 7-2 
description of, 3-18 
relation to EIP, 7-2 
ROL instruction, 7-13 
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ROR instruction, 7-13 
Rounding 
modes, floating-point operations, 4-18 
modes, x87 FPU, 8-8 
toward zero (truncation), 4-18 
Rounding control (RC) field 
MXCSR register, 4-18, 10-4 
x87 FPU control word, 4-18, 8-8 
RSI register, 3-12 
RSP register, 3-12, 6-4 
RSQRTPS instruction, 10-8 
RSORTSS instruction, 10-8 
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SAHF instruction, 3-15, 7-21 
SAL instruction, 7-10 
SAR instruction, 7-11 
Saturation arithmetic (MMX instructions), 9-4 
SBB instruction, 7-8 
Scalar operations 
defined, 10-7, 11-5 
scalar double-precision FP operands, 11-5 
scalar single-precision FP operands, 10-7 
Scale (operand addressing), 3-22, 3-23, 3-24 
Scale, x87 FPU operation, 8-21 
Scaling bias value, 8-29, 8-30 
SCAS instruction, 3-17, 7-18 
Segment 
defined, 3-7 
maximum number, 3-7 
Segment override prefixes, 3-21 
Segment registers 
64-bit mode, 3-15, 3-22, 7-2 
default usage rules, 3-21 
description of, 3-11, 3-13 
part of basic programming environment, 7-1 
Segment selector 
description of, 3-7, 3-13 
segment override prefixes, 3-21 
specifying, 3-21 
Segmented memory model, 1-7, 3-7, 3-13 
Serialization of I/O instructions, 19-5 
Serializing instructions, 19-5 
SETcc instructions, 3-17, 7-14 
SF (sign) flag, EFLAGS register, 3-16, A-1 
SF (stack fault) flag, x87 FPU status word, 8-6, 8-27 
SFENCE instruction, 10-14, 11-12, 11-25 
SHL instruction, 7-10 
SHLD instruction, 7-12 
SHR instruction, 7-11 
SHRD instruction, 7-12 
Shuffle instructions 
SSE extensions, 10-9 
SSE2 extensions, 11-7 
SHUFPD instruction, 11-7 
Sl register, 3-12 
Signaling NaN (see SNaN) 
Signed 
infinity, 4-15 
integers, description of, 4-4 
integers, encodings, 4-4 
zero, 4-14 
Significand, of floating-point number, 4-11 
Sign, floating-point number, 4-11 
SIMD floating-point exception (#XM), 11-18 
SIMD floating-point exceptions 
denormal operand exception (#D), 11-15 
divide-by-zero (#Z), 11-15 
exception conditions, 11-14 
exception handlers, D-1 
inexact result exception (#P), 11-16 


invalid operation exception (#1), 11-14 
list of, 11-13 
numeric overflow exception (#0), 11-15 
numeric underflow exception (#U), 11-16 
precision exception (#P), 11-16 
software handling, 11-18 
summary of, C-1 
writing exception handlers for, D-1 
SIMD floating-point flag bits, 10-4 
SIMD floating-point mask bits, 10-4 
SIMD floating-point rounding control field, 10-4 
SIMD (single-instruction, multiple-data) 
execution model, 2-2, 9-4 
instructions, 2-14, 5-18, 10-7 
MMxX instructions, 5-13 
operations, on packed double-precision floating-point operands, 11-4 
operations, on packed single-precision floating-point operands, 10-6 
packed data types, 4-8 
SSE instructions, 5-15 
SSE2 instructions, 11-4, 12-2, 12-6 
Sine, x87 FPU operation, 8-20 
Single-precision floating-point format, 4-4 
Sleep, 2-4 
Smart cache, 2-4 
Smart memory access, 2-11 
smart memory access, 2-4 
SMM 
memory model used, 3-9 
overview, 3-1 
SNaNs 
description of, 4-15 
effect on COMISD and UCOMISD, 11-7 
encodings, 4-5 
operating on, 4-16 
typical uses of, 4-15 
using in applications, 4-16 
Software compatibility, 1-6 
SP register, 3-12 
Speculative execution, 2-7, 2-9 
Spin-wait loops 
programming with PAUSE instruction, 11-12 
SQRTPD instruction, 11-6 
SQRTPS instruction, 10-8 
SQRTSD instruction, 11-6 
SQRTSS instruction, 10-8 
SS register, 3-13, 3-14, 6-1 
SSE extensions 
128-bit packed single-precision data type, 10-5 
64-bit mode, 10-3 
64-bit SIMD integer instructions, 10-11 
branching on arithmetic operations, 11-24 
cacheability control instructions, 10-12 
cacheability hint instructions, 11-25 
caller-save requirement for procedure and function calls, 11-24 
checking for SSE and SSE2 support, 11-19 
comparison instructions, 10-9 
compatibility mode, 10-3 
compatibility of SIMD and x87 FPU floating-point data types, 11-22 
conversion instructions, 10-11 
data movement instructions, 10-7 
data types, 10-5, 12-1 
denormal operand exception (#D), 11-15 
denormals-are-zeros mode, 10-5 
divide by zero exception (#Z), 11-15 
exceptions, 11-13 
floating-point format, 4-11 
flush-to-zero mode, 10-4 
generating SIMD FP exceptions, 11-16 
guidelines for using, 11-19 
handling combinations of masked and unmasked exceptions, 11-18 
handling masked exceptions, 11-16 
handling SIMD floating-point exceptions in software, 11-18 
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handling unmasked exceptions, 11-17, 11-18 
inexact result exception (#P), 11-16 
instruction prefixes, effect on SSE and SSE2 instructions, 11-25 
instruction set, 5-15, 10-6 
interaction of SIMD and x87 FPU floating-point exceptions, 11-18 
interaction of SSE and SSE2 instructions with x87 FPU and MMX 
instructions, 11-21 
interfacing with SSE and SSE2 procedures and functions, 11-23 
intermixing packed and scalar floating-point 
and 128-bit SIMD integer instructions 
and data, 11-22 
introduction, 2-2 
invalid operation exception (#1), 11-14 
logical instructions, 10-9 
masked responses to invalid arithmetic operations, 11-14 
memory ordering instruction, 10-14 
MMX technology compatibility, 10-5 
MXCSR register, 10-3 
MXCSR state management instructions, 10-12 
non-temporal data, operating on, 10-12 
numeric overflow exception (#0), 11-15 
numeric underflow exception (#U), 11-16 
overview, 10-1 
packed 128-Bit SIMD data types, 4-8 
packed and scalar floating-point instructions, 10-6 
programming environment, 10-2 
QNaN floating-point indefinite, 4-17 
restoring SSE and SSE2 state, 11-20 
REX prefixes, 10-3 
saving SSE and SSE2 state, 11-20 
saving XMM register state on a procedure or function call, 11-23 
shuffle instructions, 10-9 
SIMD floating-point exception conditions, 11-14 
SIMD floating-point exception cross reference, C-3 
SIMD floating-point exception (#XM), 11-17, 11-18 
SIMD floating-point exceptions, 11-13 
SIMD floating-point mask and flag bits, 10-4 
SIMD floating-point rounding control field, 10-4 
SSE and SSE2 conversion instruction chart, 11-9 
SSE feature flag, CPUID instruction, 11-19 
SSE2 compatibility, 10-5 
system programming, 13-19 
unpack instructions, 10-9 
updating MMX technology routines 
using128-bit SIMD integer instructions, 11-24 
x87 FPU compatibility, 10-5 
XMM registers, 10-3 


SSE feature flag, CPUID instruction, 11-19, 12-5 
SSE instructions 


descriptions of, 10-6 
SIMD floating-point exception cross-reference, C-3 
summary of, 5-15 
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128-bit packed single-precision 
data type, 11-3 
128-bit packed single-precision data type, 12-1 
128-bit SIMD integer instruction 
extensions, 11-11 
64-bit and 128-bit SIMD integer instructions, 11-10 
64-bit mode, 11-3 
arithmetic instructions, 11-6 
branch hints, 11-13 
branching on arithmetic operations, 11-24 
cacheability control instructions, 11-12 
cacheability hint instructions, 11-25 
caller-save requirement for procedure and function calls, 11-24 
checking for SSE and SSE2 support, 11-19 
comparison instructions, 11-7 
compatibility mode, 11-3 
compatibility of SIMD and x87 FPU floating-point data types, 11-22 
conversion instructions, 11-9 
data movement instructions, 11-5 
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data types, 11-3, 12-1 

denormal operand exception (#D), 11-15 
denormals-are-zero mode, 11-3 

divide by zero exception (#Z), 11-15 

exceptions, 11-13 

floating-point format, 4-11 

generating SIMD floating-point exceptions, 11-16 
guidelines for using, 11-19 


handling combinations of masked and unmasked exceptions, 11-18 


handling masked exceptions, 11-16 

handling SIMD floating-point exceptions in software, 11-18 

handling unmasked exceptions, 11-17, 11-18 

inexact result exception (HP), 11-16 

initialization of, 11-20 

instruction prefixes, effect on SSE and SSE2 instructions, 11-25 

instruction set, 5-18 

instructions, 11-4, 12-2, 12-6 

interaction of SIMD and x87 FPU floating-point exceptions, 11-18 

interaction of SSE and SSE2 instructions with x87 FPU and MMX 
instructions, 11-21 

interfacing with SSE and SSE2 procedures and functions, 11-23 


intermixing packed and scalar floating-point and 128-bit SIMD integer 


instructions and data, 11-22 
invalid operation exception (#1), 11-14 
logical instructions, 11-7 
masked responses to invalid arithmetic operations, 11-14 
memory ordering instructions, 11-12 
MMX technology compatibility, 11-3 
numeric overflow exception (#0), 11-15 
numeric underflow exception (#U), 11-16 
overview of, 11-1 
packed 128-Bit SIMD data types, 4-8 
packed and scalar floating-point instructions, 11-4 
programming environment, 11-2 
QNaN floating-point indefinite, 4-17 
restoring SSE and SSE2 state, 11-20 
REX prefixes, 11-3 
saving SSE and SSE2 state, 11-20 
saving XMM register state on a procedure or function call, 11-23 
shuffle instructions, 11-7 
SIMD floating-point exception conditions, 11-14 
SIMD floating-point exception cross reference, C-5 
SIMD floating-point exception (#XM), 11-17, 11-18 
SIMD floating-point exceptions, 11-13 
SSE and SSE2 conversion instruction chart, 11-9 
SSE compatibility, 11-3 
SSE2 feature flag, CPUID instruction, 11-19 
system programming, 13-19 
unpack instructions, 11-7 
updating MMX technology routines using 128-bit SIMD integer 
instructions, 11-24 
writing applications with, 11-19 
x87 FPU compatibility, 11-3 
SSE2 feature flag, CPUID instruction, 11-19, 12-5 
SSE2 instructions 
descriptions of, 11-4, 12-2, 12-6 
SIMD floating-point exception cross-reference, C-5 
summary of, 5-18 
SSE3 extensions 
64-bit mode, 12-1 
asymmetric processing, 12-1 
compatibility mode, 12-1 
DNA exceptions, 12-9 
emulation, 12-10 
enabling support in a system executive, 12-5, 12-18 
exceptions, 12-9 
guideline for packed addition/subtraction instructions, 12-6 
horizontal addition/subtraction instructions, 12-4 
horizontal processing, 12-1 
instruction that addresses cache line splits, 5-22 
instruction that improves X87-FP integer conversion, 5-22 
instructions for horizontal addition/subtraction, 5-22 


INDEX-12 Vol. 1 


instructions for packed addition/subtraction, 5-22 
instructions that enhance LOAD/MOVE/DUPLICATE, 5-23 
instructions that improve synchronization between agents, 5-23 
LOAD/MOVE/DUPLICATE enhancement instructions, 12-3 
MMX technology compatibility, 12-1 
numeric error flag and IGNNE#, 12-9 
packed addition/subtraction instructions, 12-4 
programming environment, 12-1 
REX prefixes, 12-1 
SIMD floating-point exception cross reference, C-7, C-8 
specialized 120-bit load instruction, 12-3 
SSE compatibility, 12-1 
SSE2 compatibility, 12-1 
system programming, 13-19 
x87 FPU compatibility, 12-1 
SSE3 instructions 
descriptions of, 12-2 
SIMD floating-point exception 
cross-reference, C-7, C-8 
summary of, 5-22 
SSSE3 extensions 
64-bit mode, 12-1 
asymmetric processing, 12-1 
checking for support, 12-9 
compatibility, 12-1 
compatibility mode, 12-1 
data types, 12-1 
DNA exceptions, 12-9 
emulation, 12-10 
enabling support in a system executive, 12-9 
exceptions, 12-9 
horizontal add/subtract instructions, 12-7 
horizontal processing, 12-1 
MMX technology compatibility, 12-1 
multiply and add packed instructions, 12-8 
numeric error flag and IGNNE#, 12-9 
packed absolute value instructions, 12-7 
packed align instruction, 12-8 
packed multiply high instructions, 12-8 
packed shuffle instruction, 12-8 
programming environment, 12-1 
SSSE2 compatibility, 12-1 
x87 FPU compatibility, 12-1 
SSSE3 instructions 
descriptions of, 12-6 
summary of, 5-23 
Stack 
64-bit mode, 3-5, 6-4 
64-bit mode behavior, 6-19 
address-size attribute, 6-3 
alignment, 6-2 
alignment of stack pointer, 6-2 
current stack, 6-1, 6-3 
description of, 6-1 
EIP register (return instruction pointer), 6-3 
maximum size, 6-1 
number allowed, 6-1 
overview of, 3-4 
passing parameters on, 6-7 
popping values from, 6-1 
procedure linking information, 6-3 
pushing values on, 6-1 
return instruction pointer, 6-3 
SS register, 6-1 
stack segment, 3-14, 6-1 
stack-frame base pointer, EBP register, 6-3 
switching 
on calls to interrupt and exception handlers, 6-14 
on inter-privilege level calls, 6-10, 6-17 
privilege levels, 6-8 
width, 6-2 
Stack, x87 FPU 


stack fault, 8-6 


stack overflow and underflow exception (#IS), 8-4, 8-26 


Status flags 

EFLAGS register, 3-16, 8-6, 8-7, 8-19 
STC instruction, 3-16, 7-21 
STD instruction, 3-17, 7-21 
STl instruction, 7-22, 19-3 
Sticky bits, 8-5 
STMXCSR instruction, 10-12, 11-24 
STOS instruction, 3-17, 7-19 
Streaming SIMD extensions 2 (see SSE2 extensions) 
Streaming SIMD extensions (see SSE extensions) 
String data type, 4-8 
ST(0), top-of-stack register, 8-3 
SUB instruction, 7-8 
Superscalar microarchitecture 

P6 family microarchitecture, 2-2 

P6 family processors, 2-7 

Pentium 4 processor, 2-9 

Pentium Pro processor, 2-2 

Pentium processor, 2-2 
System management mode (see SMM) 
System programming 

SSE/SSE2/SSE3 extensions, 13-19 
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Tangent, x87 FPU operation, 8-20 
Task gate, 6-18 
Task register, 3-4 
Task state segment (see TSS) 
Tasks 
exception handler, 6-18 
interrupt handler, 6-18 
Temporal data, 10-12 
TEST instruction, 7-14 
TF (trap) flag, EFLAGS register, 3-17, A-1 
Thermal Monitor, 2-4 
TOP (stack TOP) field 
x87 FPU status word, 8-2, 9-9 
TR register, 3-6 
Trace cache, 2-9 
Transcendental instruction accuracy, 8-22 
Trap gate, 6-13 
Truncation 
description of, 4-18 
with SSE-SSE2 conversion instructions, 4-18 
TSS 
I/O map base, 19-4 
I/O permission bit map, 19-4 
saving state of EFLAGS register, 3-15 


U 
UCOMISD instruction, 11-7 
UCOMISS instruction, 10-9 
UD2 instruction, 7-24 
UE (numeric underflow exception) flag 
MXCSR register, 11-16 
x87 FPU status word, 8-5, 8-29 
UM (numeric underflow exception) mask bit 
MXCSR register, 11-16 
x87 FPU control word, 8-7, 8-29 
Underflow 
FPU exception 
(see Numeric underflow exception) 
numeric, floating-point, 4-14 
x87 FPU stack, 8-26 
Underflow, x87 FPU stack, 8-26 
Unpack instructions 
SSE extensions, 10-9 
SSE2 extensions, 11-7 


UNPCKHPD instruction, 11-8 
UNPCKHPS instruction, 10-10 
UNPCKLPD instruction, 11-8 
UNPCKLPS instruction, 10-10 
Unsigned integers 
description of, 4-3 
range of, 4-3 
types, 4-3 
Unsupported, 8-14 
floating-point formats, x87 FPU, 8-14 
x87 FPU instructions, 8-24 
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VIF (virtual interrupt) flag, EFLAGS register, 3-17 
VIP (virtual interrupt pending) flag 
EFLAGS register, 3-17 
Virtual 8086 mode 
description of, 3-17 
memory model, 3-7, 3-8 
VM (virtual 8086 mode) flag, EFLAGS register, 3-17 
VMCALL instruction, 5-36 
VMCLEAR instruction, 5-35, 5-36 
VMLAUNCH instruction, 5-35, 5-36 
VMPTRLD instruction, 5-35, 5-36 
VMPTRST instruction, 5-35, 5-36 
VMREAD instruction, 5-35, 5-36 
VMRESUME instruction, 5-35, 5-36 
VMWRITE instruction, 5-35, 5-36 
VMX 
instruction set, 5-35, 5-36 
introduction, 2-20 
Virtual machine monitor (VMM), 2-20 
virtualization, 2-20 
VMXOFF instruction, 5-36 
VMXON instruction, 5-36 
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Waiting instructions, x87 FPU, 8-24 
WAIT/FWAIT instructions, 8-23, 8-31 

WC memory type, 10-12 

wide dynamic execution, 2-4 

Word, 4-1 

Wraparound mode (MMxX instructions), 9-4 
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x87 FPU 
64-bit mode, 8-1 
compatibility mode, 8-1 
control word, 8-7 
data pointer, 8-9 
data registers, 8-1 
execution environment, 8-1 
floating-point data types, 8-13 
floating-point format, 4-11 
fopcode compatibility mode, 8-10 
FXSAVE and FXRSTOR instructions, 11-23 
IEEE Standard 754, 8-1 
instruction pointer, 8-9 
instruction set, 8-15 
last instruction opcode, 8-10 
overview of registers, 3-2 
programming, 8-1 
QNaN floating-point indefinite, 4-17 
register stack, 8-1 
register stack, parameter passing, 8-3 
registers, 8-1 
save and restore state instructions, 5-13 
saving registers, 11-23 
state, 8-11 
state, image, 8-11, 8-12 
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state, saving, 8-11, 8-12 XORPD instruction, 11-7 
status register, 8-4 XORPS instruction, 10-9 
tag word, 8-8 XRSTOR, 14-15, 15-1, 15-4 
transcendental instruction accuracy, 8-22 XSAVE, 14-15, 14-20, 14-25, 14-31, 14-32, 15-1, 15-4, 15-8 
x87 FPU control word 
description of, 8-7 Zz 
exception-flag mask bits, 8-7 3 ; 
infinity control flag, 8-8 ZE (divide by zero exception) flag 
precision control (PC) field, 8-7 x87 FPU status word, 8-5, 8-28 
rounding control (RC) field, 4-18, 8-8 ZE (divide by zero exception) flag bit 
x87 FPU exception handling MXCSR register, 11-15 
description of, 8-32 Zero, floating-point format, 4-5, 4-14 
floating-point exception summary, C-1 ZF (zero) flag, EFLAGS register, 3-16, A-1 
MS-DOS compatibility mode, 8-32 ZM (divide by zero exception) mask bit 
native mode, 8-32 MXCSR register, 11-15 
x87 FPU floating-point exceptions x87 FPU control word, 8-7, 8-28 


denormal operand exception, 8-28 
division-by-zero, 8-28 
exception conditions, 8-26 
exception summary, C-1 
inexact-result (precision), 8-30 
interaction of SIMD and x87 FPU floating-point exceptions, 11-18 
invalid arithmetic operand, 8-26, 8-27 
numeric overflow, 8-28 
numeric underflow, 8-29 
software handling, 8-32 
stack overflow, 8-4, 8-26 
stack underflow, 8-4, 8-26 
summary of, 8-24 
synchronization, 8-31 
x87 FPU instructions 
arithmetic vs. non-arithmetic instructions, 8-25 
basic arithmetic, 8-17 
comparison and classification, 8-18 
control, 8-23 
data transfer, 8-16 
exponential, 8-21 
instruction set, 8-15 
load constant, 8-17 
logarithmic, 8-21 
operands, 8-15 
overview, 8-15 
save and restore state, 8-23 
scale, 8-21 
transcendental, 8-22 
transitions between x87 FPU and MMX code, 9-9 
trigonometric, 8-20 
unsupported, 8-24 
x87 FPU status word 
condition code flags, 8-4 
DE flag, 8-28 
description of, 8-4 
exception flags, 8-5 
OE flag, 8-28 
PE flag, 8-4 
stack fault flag, 8-6 
TOP field, 8-2 
top of stack (TOP) pointer, 8-4 
x87 FPU tag word, 8-8, 9-9 
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XCHG instruction, 7-4 
XCRO, 14-15 
XFEATURE_ENALBED_MASK, 15-4 
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description, 10-3 
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overview of, 3-2 
parameters passing in, 11-23 
saving on a procedure or function call, 11-23 
XOR instruction, 7-10 
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